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ABSTRACT 


The  author  presents  a  new  framework  for  evaluating  the  evolutionary  upgrade  paths 
of  command,  control,  and  communications  systems.  C3  system  procurements  today  can 
be  viewed  as  upgrades  to  existing  C3  systems.  Most  operational  C3  functions  are 
performed  today  by  commanders  and  their  staffs  with  various  levels  of  automated 
support.  The  upgrade  procurements  are  intended  to  increase  or  improve  this  automated 
support.  The  author  examines  the  shrinking  budget,  technology  initiatives,  Evolutionary 
Acquisition,  Commercial-Off-The-Shelf  (COTS),  Non-Developmental-Items  (NDI),  and 
emerging  open  architecture  standards.  Current  evaluation  frameworks,  the  Mission- 
Oriented  Approach  (MOA),  the  Modular  Command  and  Control  Evaluation  Structure 
(MCES),  and  a  Cost  and  Operational  Effectiveness  Anaylsis  (COEA),  are  examined.  An 
illustration  of  the  framework  uses  the  United  States  Marine  Corps’  Tactical  Combat 
Operations  (TCO)  System.  Conclusions  stress  that  C3  systems  can  be  viewed  as 
evolutionary  upgrade  paths  that  change  over  time,  that  effective  evaluations  of 
evolutionary  C3  systems  must  consider  the  temporal  component,  and  that  a  framework, 
such  as  the  one  presented  in  this  thesis,  is  needed  for  comparing  alternative  upgrade 
paths  rather  than  alternative  static  C3  systems. 
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I.  INTRODUCTION 


A.  PURPOSE  OF  THESIS 

The  purpose  of  this  thesis  is  to  present  a  new  framework  for  evaluating  alternative 
evolutionary  upgrade  paths  for  command,  control,  and  communications  systems. 
Unprecedented  changes  in  the  international  strategic  environment,  coupled  with 
increasing  domestic  budgetary  pressures,  necessitated  a  shift  in  US  defense  strategy  and 
are  reflected  in  the  new  national  military  strategy  published  in  January  1992.  The  new 
strategy  shifts  its  focus  from  containing  communism  and  deterring  Soviet  aggression  to 
a  more  flexible,  regionally  oriented  strategy  capable  of  countering  a  wide  range  of 
potential  threats  to  vital  US  interests.  [Ref.  l:p.  II-l]  Guidance  on  changing  C4  systems 
and  objectives  have  lead  to  initiatives  such  as  C*I  for  Warrior,  the  Navy’s  Copernicus 
concept,  and  the  Navy  and  Marine  Corp’s  "...From  the  Sea"  strategy.  Specifically,  in 
the  area  of  acquisitions,  the  use  of  an  evolutionary  type  acquisition  concept  for  the 
acquisition  of  new  C3  systems  is  now  mandated  by  DoD  [Ref.  2:p.  5-A-5]. 

Most  C3  systems  that  are  procured  today  and  in  the  future  will  undoubtedly 
incoiporate  incremental  evolutionary  upgrades  during  their  useful  life  cycle.  The  author 
proposes  a  methodology  for  evaluating  alternative  C3  systems  that  considers  this  temporal 
component  by  evaluating  incremental  upgrade  paths. 
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B.  METHODOLOGY 


In  order  to  understand  the  problems  associated  with  evaluating  C3  systems,  the 
major  issues  that  effect  C3  system  evaluation  will  be  discussed.  Then,  the  merits  of  some 
the  current  evaluation  frameworks  will  be  examined  followed  by  the  introduction  of  the 
new  framework.  To  clarify  the  concepts  introduced  by  the  new  framework,  an  illustrated 
example  is  presented  using  the  United  States  Marine  Corp’s  Tactical  Combat  Operations 
(TCO)  system. 

A  major  issue  the  new  framework  will  address  is  the  difficult,  but  ever  present, 
temporal  component  of  C3  systems.  The  author  proposes  that  effective  evaluations  of 
new  C3  systems  must  include  an  evaluation  of  its  planned  upgrade  path  toward  some  goal 
or  target  level  of  functionality. 

C.  SCOPE  OF  THESIS 

The  main  focus  of  this  thesis  is  to  present  a  useful  framework  for  evaluating 
evolutionary  upgrade  paths  of  C3  systems.  Only  a  general  discussion  of  the  important 
issues  that  effect  evaluations  will  be  given  to  characterize  the  evolutionary  environment. 
The  thesis  will  only  address  those  issues  that  effect  generic  C3  systems.  After  the 
framework  is  presented,  an  illustration  will  be  presented  using  the  TCO  alternative 
systems  established  by  the  Marine  Corps  about  the  time  of  this  writing.  All  values  and 
costs  used  in  the  illustration  are  chosen  for  illustrative  purposes  only  due  to  the 
unavailability  of  actual  values. 
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In  order  to  maintain  a  smooth  flow  between  the  discussion  of  the  framework  in 
Chapter  III  and  the  illustration  in  Chapter  IV,  the  background  and  history  of  TCO  and 
the  Marine  Tactical  Command  and  Control  System  (MTACCS)  will  be  presented  in 
Section  D  of  this  chapter. 

D.  DEFINITION 

The  official  Department  of  Defense  (DoD)  definition  for  a  command,  control,  and 
communications  system  is: 

The  facilities,  equipment,  communications,  procedures,  and  personnel  essential  to 
a  commander  for  planning,  directing,  and  controlling  operations  of  assigned  forces 
pursuant  to  the  missions  assigned. 

A  command,  control,  and  communications  (C3)  system  is  a  collection  of  tools  the 
decision  maker  uses.  It  is  a  collection  of  facilities,  equipment,  communications, 
procedures,  and  personnel  that  helps  the  decision  maker  gather,  process,  and  disseminate 
information.  [Ref.  3:p.  1]  With  the  increasing  reliance  on  computer  systems,  the  term 
command,  control,  communication,  and  computers  (C4)  is  also  widely  used.  Likewise, 
C*I  and  C4]?  have  been  popular  terms  that  highlight  the  contributions  of  intelligence  and 
interoperability. 

To  avoid  confusion,  the  author  will  strictly  use  the  term  C3  system.  C3  systems  can 
also  be  viewed  as  a  collection  of  tools  that  provide  automated  support  to  those  functions 
that  commanders  have  always  performed  (e.g.,  planning,  directing  and  controlling  his 
forces).  Most  operational  Command,  Control,  and  Communications  (C3)  functions  are 
done  today,  but  the  level  of  automation  of  each  function  varies  from  system  to  system. 
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Upgrades  to  C3  systems  will  either  fully  automate  a  C3  function  or  provide  automated 
support  to  the  function.  In  either  case,  it  will  be  referred  to  as  automating  the  function.1 
Some  C3  functions  may  even  stay  manual. 

E.  BACKGROUND  AND  HISTORY  OF  MTACCS  AND  TCO 

The  Marine  Tactical  Command  and  Control  System  (MTACCS)  is  the  Marine 
Corp’s  current  command  and  control  concept  and  is  compliant  with  the  goals  of  C4I  for 
the  Warrior.  It  stresses  the  integration  of  separate  automation  assisted  Marine  Air 
Ground  Task  Force  (MAGTF)  C3  systems  which  support  tactical  operations.  MTACCS 
enhances  the  commander’s  decision  making  capability  and  provides  tools  necessary  for 
effective  and  efficient  C2  on  the  battlefield. 

1.  Background  and  History  of  MTACCS 
a.  The  Need 

The  National  Security  Act  of  1947  requires  that  the  Marine  Corps 
provide  rapidly  deployable  amphibious  forces  for  contingency  missions  in  support  of  the 
national  strategy.  A  key  statutory  mission  of  the  Marine  Corps  is  to  provide  MAGTFs 
for  service  with  the  fleet  in  the  seizure  or  defense  of  advanced  naval  bases  and  for  the 
conduct  of  such  land  operations  as  may  be  essential  to  the  prosecution  of  a  naval 
campaign.  The  coordination  of  such  a  large  number  of  forces  and  equipment  deployed 
over  a  wide  geographic  area  demonstrates  the  requirement  for  an  automated  C3  system 
to  effectively  manage  the  assets  available.  [Ref.  4:p.  1] 

1  These  aspects  will  be  expanded  upon  in  Chapter  III. 
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An  automated  C3  system  that  can  be  used  in  peace  as  well  as  combat 
would  facilitate  the  prosecution  of  battle  and  make  more  effective  use  of  available 
resources. 

b.  Historical  Summary 

The  MTACCS  concept  started  with  C2  studies  conducted  during  1965  and 

1966,  which  resulted  in  the  Marine  Corps  General  Operational  Requirements  (GOR)  No. 
CC-9,  Marine  Corps  Tactical  Command  and  Control  Systems  (MTACCS),  issued  in 

1967.  The  USMC  issued  the  first  MTACCS  Master  Plan  in  1976  to  provide  policy  and 
guidance  for  the  integrated  management  of  efforts  to  improve  tactical  C2.  The  last  update 
of  that  plan  was  in  1981.  Beginning  in  1983,  Headquarters  Marine  Corps  (HQMC) 
incorporated  the  MTACCS  Master  Plan  into  the  Marine  Corps  Command  and  Control 
Master  Plan  (C2MP),  last  revised  in  August  of  1987.  Termination  of  the  Marine 
Integrated  Fire  and  Air  Support  System  (MIFASS),  a  cornerstone  of  MTACCS  in  the 
original  concept,  caused  the  MTACCS  philosophy  to  enter  a  two  year  period  of 
dormancy.  Only  nominal  integration  of  tactical  data  systems  occurred  during  that  period. 
The  current  MTACCS  program  will  revitalize  the  original  concept,  update  it  to  reflect 
the  current  needs  of  the  MAGTF,  and  bring  a  modem  tactical  C3  system  to  fruition. 
[Ref.  5:pp.  1-3] 

The  objective  of  the  MTACCS  concept  is  to  provide  MAGTF 
commanders  with  an  integrated  set  of  systems  which  can  receive,  process,  display,  store, 
and  distribute  essential  information.  Figure  1  portrays  the  MTACCS  concept  as  it  is 
currently  envisioned. 
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MARINE  TACTICAL  COMMAND  AND  CONTROL  SYSTEM 


Figure  1:  Marine  Tactical  Command  and  Control  System 


2.  Background  and  History  of  TCO 
a.  Background 

Marine  tactical  commanders  face  unprecedented  challenges  in  exercising 
C2  on  the  modem  battlefield.  The  tempo  of  operations  has  increased,  the  MAGTF 
commander’s  area  of  interest  has  expanded,  and  more  data  is  required  to  support  tactical 
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decision  making.  The  ability  to  gather,  process,  and  disseminate  tactical  information  is 
critical  to  the  operational  success  of  the  MAGTF.  The  Marine  Corps  has  long- 
recognized  the  need  for  an  automated  system  to  improve  these  C2  capabilities  and  first 
identified  this  requirement  as  General  Operational  Requirement  Number  CC-9  of  28  July 
1967.  The  requirement  for  the  TCO  system  is  documented  in  MNS,  No.  CCC  1.31A, 
approved  by  the  Assistant  Commandant  of  the  Marine  Corps  and  issued  by  the 
Commanding  General,  Marine  Corps  Combat  Development  Command  (MCCDC),  on  16 
June  1992.  Technology  is  now  available  to  support  development  of  a  command  and 
control  system  that  will  significantly  enhance  the  commander’s  ability  to  plan  and  execute 
MAGTF  operations.  [Ref.  6:p.  1-1] 

b.  Operational  Concept 

The  new  approved  standard  general  description  of  TCO  as  it  is  published 
in  Campaign  Plan  1-  93  is  as  follows: 

The  Tactical  Combat  Operations  (TCO)  system  will  serve  as  the  operations 
component  to  the  Marine  Tactical  Command  and  Control  System  (MTACCS). 
TCO  will  use  microcomputers  to  provide  commanders  the  automation  to  receive, 
fuse,  select,  and  display  information  from  many  sources,  and  disseminate  selected 
information  throughout  the  battlefield.  TCO  attributes  include:  automated  message 
processing,  mission  planning,  development  and  dissemination  of  operations  orders 
and  overlays,  display  of  current  friendly  and  enemy  situations,  display  of  tactical 
control  measures,  and  interfaces  with  local  and  wide  area  networks.  [Ref.  7:p.  C- 
2-1] 

TCO  will  be  employed  at  the  Command  Element  of  the  Marine 
Expeditionary  Force  (MEF),  the  Marine  Expeditionary  Brigade  (MEB),  and  the  Marine 
Expeditionary  Unit  (MEU).  All  staff  sections  of  the  MAGTF  command  element  will 
interface  with  TCO.  The  system  will  support  MAGTF  commanders  and  their  staffs 
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down  to  the  battalion  level  in  the  Ground  Combat  Element,  down  to  the  squadron  level 
in  the  Aviation  Combat  Element,  and  down  to  the  battalion  (and  possibly  company)  level 
in  the  Combat  Service  Support  Element.  The  principle  users  of  TCO  will  be  the 
MAGTF  commanders  and  their  operations  staff.  Operators  will  be  watch  officers  and 
trained  enlisted  personnel. 

The  TCO  system  is  designed  to  enhance  the  commander’s  ability  to  focus 
on  critical  elements  of  information  while  making  battlefield  decisions.  It  will  use  state- 
of-the-art  technology  to  provide  a  mobile,  flexible,  and  reliable  system  that  is  able  to 
interface  with  existing  Marine  Corps,  other  services,  and  joint  systems. 

TCO  will  be  composed  of  computerized  workstations,  connected  by  the 
designated  Marine  Corps  standard  local  area  networks  (LAN)  within  each  command  post. 
These  workstations  will  provide  a  graphical  user  interface  and  keyboard  and/or  pointing 
device;  information  processing  and  display;  graphics;  communications  interface;  and  hard 
copy  printout.  LANs  will  be  interconnected  by  wide  area  networks  to  other 
geographically  dispersed  command  posts  (CPs)  via  tactical  communications  assets. 
Separate,  but  reconfigurable,  workstations  are  used  for  conduct  of  current  operations  and 
planning.  This  redundancy  supports  continuity  of  operations  during  CP  displacement. 
[Ref.  6:p.  1-5] 

3.  Current  Status  of  TCO 

The  Marine  Corps  Combat  Development  Command  (MCCDC)  Studies  and 
Analysis  Division  is  currently  doing  a  Cost  and  Operational  Effectiveness  Analysis 
(COEA)  on  the  selected  TCO  alternatives.  These  alternatives  will  provide  automated 
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support  for  many  of  the  functions  presently  handled  manually  in  the  Combat  Operations 
Center.  The  following  paragraphs  outline  briefly  the  current  alternative  systems  being 
considered  for  fulfilling  the  requirements  of  TCO. 

a.  Base  Case 

This  alternative  would  be  to  continue  the  status  quo.  Fleet  Marine  Force 
(FMF)  units  are  currently  using  organic  tactical  communications,  microcomputers,  and 
the  tactical  digital  facsimile  to  establish  C2  networks.  These  locally  developed  networks 
partially  satisfy  FMF  requirements  for  automated  support  of  operations  planning  and 
execution.  Applications  include  locally  developed  programs  tailored  to  support  the  needs 
of  individual  units  as  well  as  programs  distributed  Marine  Corps-wide.  However,  they 
are  unique  to  a  particular  MEF. 

b.  Maneuver  Control  System  (MCS) 

Under  this  alternative,  MCS  Version  11  software  would  be  modified  to 
satisfy  TCO  requirements.  MCS  is  a  component  of  the  Army  Tactical  Command  and 
Control  System  designed  to  provide  support  for  operations  planning  and  execution. 
Version  10  of  MCS  is  currently  fielded.  Version  10  provides  minimum  capability  and 
imposes  a  significant  logistics  burden.  Version  11  is  being  developed  by  LORAL  under 
contract  to  the  U.S.  Army  Communications-Electronics  Command.  MCS  Version  11 
will  collect,  store,  retrieve,  process,  and  disseminate  tactical  information.  A  digital  map 
and  graphic  overlay  capability  is  provided.  MCS  Version  1 1  will  operate  in  either  a 
standalone  or  LAN  configuration  on  a  common  set  of  computers  from  the  Army  Tactical 
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Automated  Command  and  Control  System  Common  Hardware  and  Software  program. 
Communications  interfaces  are  provided  to  the  Army  tactical  communications  networks, 
which  include  single  channel  radio,  mobile  subscriber  equipment,  and  the  Army  Data 
Distribution  System  (EPLRS/JTIDS). 

c.  Command  Tactical  Information  System  (CTIS) 

Under  this  alternative  CTIS  software  would  be  modified  to  meet  TCO 
requirements.  CTIS  is  a  C2  system  developed  by  and  fielded  within  the  Alaskan 
Command.  CTIS  currently  operates  in  an  Apple  Macintosh  environment  and  is  being 
ported  to  a  UNIX-based,  open  systems  environment.  CTIS  uses  commercial  and  tactical 
phone  lines  and  commercial  modems  for  data  communications.  CTIS  provides  the 
battlefield  commander  a  tool  for  collecting,  storing,  processing,  and  displaying 
information.  CTIS  has  a  digital  mapping  and  graphic  overlay  capability. 

d.  Intelligence  Analysis  System  (IAS) 

This  alternative  would  satisfy  TCO  requirements  through  modification 
of  the  IAS.  IAS  is  designed  to  support  tactical  intelligence  collection,  processing,  and 
dissemination  down  to  battalion  level.  The  IAS  is  being  developed  by  the  Marine  Corps 
Tactical  Systems  Support  Activity  (MCTSSA)  at  Camp  Pendleton,  California.  IAS  is 
currently  hosted  on  a  SPARC  2  server/workstation  running  a  SunOS  UNIX  operating 
system.  IAS  supports  generation  of  digital  maps  and  overlays  depicting  the  current 
situation.  Information  that  can  be  displayed  includes  tactical  control  measures,  targets, 
standard  military  symbology,  and  unit  status  data.  IAS  uses  Defense  Mapping  Agency 
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(DMA)  map  products.  Other  capabilities  include  U.S.  Message  Text  Format  message 
preparation,  ad  hoc  data  base  query,  and  generation  of  plans  and  orders.  IAS  Version 
1.2  is  currently  fielded  and  has  been  used  in  a  Special  Operations  Command  Exercise  by 
24  MEU.  Version  2.0  is  scheduled  for  release  during  the  second  quarter  FY  93  and  will 
provide  a  substantial  enhancement  to  IAS  communications  capabilities. 

e.  Combat  Information  Processor  (CIP) 

Under  this  alternative,  the  Marine  Corps  would  continue  the  development 
of  CIP  to  incorporate  additional  capabilities  required  for  TCO.  CIP  was  developed  by 
the  Advanced  Sensors  Systems  Branch  of  the  Harry  Diamond  Laboratories  in  support 
of  the  Amphibious  Warfare  Technology  Directorate  of  Marine  Corps  Systems  Command. 
This  development  was  conducted  as  an  advanced  technology  demonstration  prototype. 
The  CIP  system  is  housed  in  an  environmentally  controlled  Standard  Integrated 
Command  Post  Shelter  mounted  on  a  M1037  High  Mobility  Multipurpose  Wheeled 
Vehicle.  The  system  provides  situation  awareness  through  a  sophisticated  digital  map 
capability. 

f.  Naval  Tactical  Command  System-Afloat  (NTCS-A) 

Under  this  alternative,  the  Marine  Corps  would  extend  NTCS-A  to  meet 
TCO  requirements.  NTCS-A  is  managed  by  the  Space  and  Naval  Warfare  Systems 
Command  and  developed  by  the  Research,  Development,  Testing  and  Evaluation 
(RDT&E)  Division  of  the  Naval  Command,  Control,  and  Ocean  Surveillance  Center. 
NTCS-A  application  programs  include  functional  applications,  such  as  the  Joint 
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Operations  Tactical  System  and  the  Naval  Intelligence  Processing  System,  incorporated 
into  unified  builds.  NTCS-A  relies  on  shipboard  front-end  processing  and  media  access 
for  local  and  external  communications.  NTCS-A  can  access  various  communications  re¬ 
sources  (AUTODIN,  tactical  link  communications  and  TTY)  through  the  communications 
server/front-end  processor.  The  NTCS-A  provides  the  Navy  tactical  commander  the 
information  necessary  to  plan  and  execute  operations. 

g.  Maestro 

Command  Systems  Incorporated  (CSI)  developed  the  FDS-1  TCO  proto¬ 
type.  Since  that  time,  CSI  has  continued  to  work  on  automated  C2  systems  and  is 
currently  marketing  a  product  called  Maestro.  Under  this  alternative,  the  Marine  Corps 
would  acquire  the  current  version  of  Maestro  and  modify  the  software  to  meet  the  TCO 
requirements.  The  current  version  of  Maestro  runs  on  a  DOS  operating  system. 
Maestro  would  have  to  be  ported  to  run  on  the  UNIX  operating  system  using  an  X- 
Windows/Motif  GUI.  Maestro  uses  scanned  paper  maps  and  overlays  to  depict  the 
current  situation.  Information  that  can  be  displayed  includes  tactical  control  measures, 
targets,  standard  military  symbology,  and  unit  status  data.  [Ref.  8:pp.  iv-vi] 

F.  OUTLINE  OF  CHAPTERS 
I.  Chapter  II.  The  Issues 

In  this  chapter,  the  important  issues  of  the  emerging  evolutionary 
procurement  environment  are  discussed.  Issues  such  as  current  technology  initiatives. 
Evolutionary  Acquisition,  Non-Developmental-Items  (NDI),  Commercial-Off-The-Shelf 
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(COTS)  products,  and  "open  system"  standards  are  presented  along  with  their  effect  on 
the  procurement  of  C3  systems.  The  Mission-Oriented  Approach  (MOA),  the  Modular 
Command  and  Control  Evaluation  Structure  (MCES),  and  the  Cost  and  Operational 
Effectiveness  Analysis  (COEA)  team’s  evaluation  approach  are  presented  to  highlight  the 
current  methodologies  and  frameworks  used  to  evaluate  C3  systems. 

2.  Chapter  HI.  A  New  Framework 

In  this  chapter,  a  new  framework  for  evaluating  evolutionary  upgrade  paths 
of  C3  system  alternatives  is  presented.  The  framework  is  a  functionally-oriented, 
capability-based  approach  that  is  intended  to  be  a  useful  step  by  step  method  that 
produces  valuable  information  about  the  upgrade  paths  of  selected  alternatives.  Each  step 
of  the  framework  is  presented  along  with  recommended  methods  and  procedures  for 
accomplishing  each  step. 

3.  Chapter  TV.  An  Illustrated  Application 

In  this  chapter,  an  illustration  of  the  framework  will  be  done  using  the  Marine 
Corp’s  Tactical  Combat  Operations  (TCO)  system.  The  illustration  will  clarify  how  to 
apply  the  concepts  and  procedures  of  the  framework.  A  simple  step  by  step  discussion 
of  how  to  perform  each  step  of  the  framework  will  be  presented  using  subjective  data  do 
to  the  unavailability  of  actual  data. 
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n.  THE  ISSUES 


A.  INTRODUCTION 

Several  recent  initiatives  such  as  DoD’s  Corporate  Information  Management 
initiative  and  the  Joint  Chiefs  of  Staffs  "C4I  for  the  Warrior"  plan  have  proposed  new 
ways  to  do  business.  These  initiatives  serve  to  create  a  procurement  environment  that 
is  business-driven,  strategically  planned,  standards  based,  integrated,  evolutionary,  and 
more  efficient.  C3  systems  procured  in  this  environment  will  utilize  Evolutionary 
Acquisition  and  incorporate  Non-Developmental-Items,  Commercial-Off-The-Shelf 
products,  and  "open  systems"  standards. 

In  order  to  accurately  and  effectively  evaluate  current  or  future  C3  systems,  the 
current  and  future  environment  in  which  they  are  acquired  must  be  understood.  This 
chapter  will  discuss  aspects  of  C3  system  procurement  today,  the  current  C3  technology 
initiatives,  evolutionary  acquisition,  and  open  architecture  standards.  Some  current 
evaluation  frameworks  will  then  be  discussed  to  highlight  the  methodologies  in  use  today. 

B.  C3  SYSTEMS  TODAY 

C3  system  procurements  today  can  be  viewed  as  upgrades  to  existing  C3  systems. 
Most  operational  C3  functions  are  performed  today  by  commanders  and  their  staffs  with 
various  levels  of  automated  support.  The  procurements  are  intended  to  increase  or 
improve  this  automated  support.  Even  large  procurements  that  make  sweeping  changes 
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(e.g.,  new  C3  systems)  will  be  incremental  and  evolutionary.  Therefore,  it  is  useful  to 
explicitly  embrace  the  evolutionary  upgrade  concept,  and  develop  a  framework  for 
comparing  alternative  upgrade  paths  rather  than  alternative  static  C3  systems. 

C.  TECHNOLOGY  INITIATIVES 
1.  Current  State  of  Technology 

America  is  in  the  midst  of  a  technological  revolution  that  will  dramatically 
change  the  way  companies  and  DoD  do  business.  NCR  Chairman  and  CEO  Gilbert 
Williamson  has  said: 

"...The  one  constant  of  the  information  technology  industry  is  change-rapid 
change...."2 

This  continuing  changing  nature  of  technologies  will  directly  effect  the  C3  systems  that 
incorporate  new  technologies. 

New,  advanced  technologies  can  permit  significant  restructuring  in  the  way 
information  is  acquired,  processed,  and  disseminated.  Some  functions  requiring 
expensive  and  scarce  resources  can  be  centralized  and  automated  to  reduce  required 
equipment,  facilities,  and  skilled  personnel.  Reliable,  wideband  communications  can 
enable  centralized  support  to  be  rapidly  provided  to  deployed  forces.  [Ref.  l:p.  III-15] 


2  Taken  from  an  article  titled  "Users  Call  the  Shots,  Says  NCR  CEO  in  Expo  Keynote"  in 
PC  Week  Magazine,  29  June  1992. 
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2.  Key  Technologies 

In  May  of  1985,  the  Assistant  Secretary  of  Defense  for  C3I  tasked  the 
Defense  Communications  Agency3  to  undertake  a  projection  and  assessment  of  the 
impact  of  technology  on  the  future  C3  systems  of  the  DoD.  DISA  published  the  report 
called  "Report  of  C3  Technology  Assessment"  in  January,  1987.  The  C3  Technology 
Assessment  concluded  that  the  DoD  should  exploit  technological  opportunities  to  effect 
profound  improvements  in  future  C3  system  in  the  following  areas: 

1.  To  make  C3  systems  "smarter"; 

2.  To  improve  software  productivity; 

3.  To  provide  for  the  distribution  of  C3  assets  for  survivability;  and 

4.  To  cope  with  security  vulnerabilities. 

Above  all,  it  will  require  further  emphasis  on  systems  engineering  and 
technology  transition;  and  the  use  of  technology  in  growing  C3  capabilities  in  place,  in 
contrast  to  building  C3  tum-kev  systems.  The  report  highlighted  that  this  will  require 
further  R&D  work  in  seven  major  technology  categories: 

1.  Distributed  C3  Systems. 

2.  Telecommunications  Technology. 

3.  Command  Decision  Support  Systems. 

4.  Information  Security. 

3  Now  called  the  Defense  Information  Systems  Agency  (DISA). 
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5.  Software  Engineering. 

6.  Artificial  Intelligence. 

7.  Photonics. 

The  report  stimulated  the  continuation  of  the  C3  technology  assessment  effort, 
including  the  conduct  of  additional  workshops  and  the  initiation  of  work  on  protocols  and 
standards  within  the  framework  of  an  overall  C3  technical  architecture.  [Ref.  9] 

3.  The  Effect  on  C3  systems 

Technological  research  will  continually  produce  advances  that  will  improve 
and  streamline  the  way  C3  systems  perform  their  mission.  New  advances  will  provide 
new  capabilities  that  will  enable  current  C3  systems  to  provide  better  automated  support 
to  the  C3  functions  it  supports.  As  new  capabilities  become  available,  existing  C3 
systems  will  incrementally  add  these  capabilities  by  incorporating  several  upgrades  during 
their  useful  life  cycle.  This  results  in  a  temporal  component  that  must  be  dealt  with. 

The  evolutionary  acquisition  concept  has  been  recognized  as  the  best  way  to 
incorporate  these  new  technology  based  capabilities  into  existing  C3  systems.  The 
following  section  will  discuss  this  concept. 

D.  THE  EVOLUTIONARY  ENVIRONMENT 

It  has  long  been  recognized  that  the  standard  DoD  weapon  system  acquisition 
process  is  poorly  suited  to  the  acquisition  of  C3  systems.  Instead,  an  evolutionary- 
process  of  "growing"  a  C3  system-"build  a  little,  test  a  little"-has  recently  been 
advocated.  [Ref.  10:p.  6]  The  National  Military  Strategy  Document  for  FY  94-99.  the 
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"C4I  for  the  Warrior"  plan,  and  DoD  Instruction  5000.2,  "Defense  Acquisition 
Management  Policy  and  Procedures" ,  all  mandate  the  use  of  evolutionary  acquisition  for 
the  procurement  of  DoD  C3  systems. 

In  the  late  1980’s,  General  Alfred  M.  Gray  (Commandant  of  the  Marine  Corps)  put 
out  initiatives  to  reorganize  the  Marine  Corp’s  equipment  acquisition  and  combat 
development  processes.  The  evolutionary  acquisition  approach  to  command  and  control 
was  adopted.  A  "build  a  little,  test  a  little,  field  a  little"  strategy  was  put  in  place.  [Ref. 

11] 


Section  1  will  describe  the  evolutionary  acquisition  concept  and  discuss  the 
advantages  of  it.  The  advantages  and  disadvantages  of  Non-Developmental  Items  and 
Commercial-Off-The-Shelf  products  will  be  presented  in  Section  3  and  Section  4  will 
discuss  how  Evolutionary  Acquisition  will  effect  C3  systems. 

1.  Evolutionary  Acquisition 

The  "Evolutionary  Acquisition"  concept  is  a  "build  a  little,  test  a  little,  field 
a  little"  approach  using  off-the-shelf  equipment  and  software  where  applicable. 
Evolutionary  Acquisition  is  defined  as: 

An  acquisition  strategy  which  may  be  used  to  procure  a  system  expected  to  evolve 
during  development  within  an  approved  architectural  framework  to  achieve  an 
overall  systems  capability.  An  underlying  factor  in  Evolutionary  Acquisition  is  the 
need  to  field  a  well  defined  core  capability  quickly  in  response  to  a  validated 
requirement,  while  planning  through  an  incremental  upgrade  program  to  eventually 
enhance  the  system  to  provide  the  overall  system  capability.  These  increments  are 
treated  as  individual  acquisitions,  with  their  scope  and  context  being  the  result  of 
both  continuous  feedback  from  developing  and  independent  testing  agencies  and  the 
user....  [Ref.  12:p.  23] 
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Evolutionary  acquisition  is  an  alternative  acquisition  process  used  to  acquire 
C3  systems  that  are  expected  to  evolve  during  development  and  throughout  their 
operational  life.  Figure  2  graphically  represents  the  application  of  an  evolutionary 
acquisition  approach.  The  initial  preliminary  system  architecture  is  segregated  into 
planned  increments.  Those  increments  are  then  refined,  funded,  and  developed  in  stages. 
[Ref.  13] 
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2.  Advantages  of  Evolutionary  Acquisition 

There  are  several  reasons  for  choosing  an  evolutionary  acquisition  approach: 

a.  Lessons  Learned  From  Past  Failures 

The  Marine  Corps’  attempt  at  the  "big  system  approach"  for  acquiring 
the  MIFASS4  system  has  failed  miserably  in  the  past  at  extreme  cost.  [Ref.  14]  It  was 
simply  too  hard  to  adjust  requirements  and  specifications  to  keep  up  with  both  user 
demand  and  technology,  and  quickly  incorporate  these  adjustments  into  a  system.  [Ref. 
15:p.  16]  Using  Evolutionary  Acquisition,  improvements  or  changes  can  be  made  at  the 
next  incremental  upgrade  and  can  be  made  easily  if  the  original  core  design  was  built 
with  the  changes  in  mind. 

b.  Lack  of  Complete  List  of  Defined  Requirements 

A  complete  list  of  C3  automation  or  support  requirements  would  be 
impossible  to  generate.  The  introduction  of  new  technology  and  procedures  makes  old 
tasks  easier  and  opens  the  door  to  provide  new  capabilities.  This  makes  it  difficult  to 
predict  the  final  requirements.  [Ref.  15:p.  16]  By  using  Evolutionary  Acquisition,  the 
user  can  provide  timely,  accurate  feedback  of  what  he/she  wants,  needs,  and  actually 
uses.  This  feedback  can  be  applied  to  the  next  increment  and  tested. 


4  MIFASS  was  a  subsystem  program  under  MTACCS  which  failed  for  several  reasons  in 
1987.  A  comprehensive  discussion  of  MIFASS  can  be  found  in  Chapter  II  of  Reference  14. 
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c.  Political  Acceptance  of  Evolutionary  Acquisition 

The  use  of  Evolutionary  Acquisition  as  an  alternative  acquisition  strategy 
is  consistent  with  the  guidance  of  the  Office  of  Management  and  Budget  Circular  A- 109, 
DoD  Directive  5000.1,  and  with  Defense  Acquisition  Circular  76-43.  Evolutionary 
Acquisition  encourages  regular  and  continual  interaction  with  the  Deputy  Program 
Managers5,  requirements  proponents,  users,  developers,  testers,  and  logisticians.  It 
encourages  the  consideration  of  Non-Developmental-Items  (NDI)  and  Commercial-Off- 
the-Self  (COTS)  material  where  applicable.  [Ref.  15  :p.  16]  By  this  continual 
interaction,  the  risk  of  spending  a  large  amount  of  resources  with  no  measurable  return 
is  reduced.  The  program  is  reviewed  by  all  concerned  at  each  increment.  Those 
responsible  for  certain  fields  will  have  to  interact  repeatedly  with  those  responsible  for 
the  other  fields  that  effect  them. 

d.  User  Response  is  Quickly  Incorporated 

By  starting  with  equipment  and  procedures  the  user  is  already  familiar 
with,  and  incorporating  a  limited  amount  of  change  at  each  increment,  the  user  can  easily 
assimilate  and  evaluate  the  change,  providing  appropriate  and  accurate  feedback. 

e.  Capabilities  are  Fielded  Faster 

Evolutionary  Acquisition  permits  faster  fielding  of  core  capabilities  to 
the  user.  It  allows  building  on  existing  equipment  and  systems  to  quickly  field  a  useful 
core  capability  and  concurrently  develop  component  systems,  capitalizing  on  the  ability 

5  Deputy  Program  Managers  are  responsible  for  subsystems  of  a  major  acquisition  program. 

They  report  to  the  Program  Manager  (PM). 
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to  incorporate  component  systems  as  they  complete  their  individual  development  phases. 
This  permits  new  technology  to  reach  the  user  at  a  rate  that  is  much  faster  than  currently 
possible. 

3.  Non-Developmental  Items  and  Commercial-Off-The-Shelf  Products 

Non-Developmental  Items  and  Commercial-Off-the-Shelf products  are  generic 
terms  that  describe  material  available  from  a  variety  of  sources  with  little  or  no 
development  be  the  government.  These  are  items  that  are  either  available  in  the 
commercial  market  place  or  from  other  services. 

According  to  William  H.  Taft  IV6,  "The  use  of  Off-The-Shelf  sources  is  a 
major  initiative  of  the  Department  of  Defense  [Ref.  16:p.  103].  There  is  considerable 
motivation  to  pursue  this  element  of  acquisition  strategy  wherever  possible.  Non- 
Developmental  Items  yield  several  benefits: 

1.  The  lime  in  development  and  the  time  to  fielding  is  greatly  reduced. 

2.  User’s  requirements  and  needs  can  be  met  and  satisfied  quickly. 

3.  Costs  for  Research  and  Development  are  reduced. 

4.  Current,  state  of  the  are  technology  is  used  and  fielded.  [Ref.  17] 


6  Former  Deputy  Secretary  of  Defense. 
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However,  there  are  risks  involved  with  using  Non-Developmental  Items. 


These  include: 


1.  Cost  and  performance  tradeoffs  to  accommodate  the  use  of  NDI  components  in 
production. 

2.  The  resulting  proliferation  of  hardware  and  software  can  cause  logistic  support, 
training,  and  configuration  management  problems  and  possible  increased  life 
cycle  costs. 

3.  Safety  deficiencies  may  occur  because  the  NDI  was  not  built  specifically  for  a 
military  environment.  [Ref.  17] 


The  benefits  of  using  NDI  should  aid  in  the  fielding  of  C3  systems 
tremendously.  The  risks  are  being  minimized  through  the  use  of  the  common  hardware 
and  common  software.  By  restricting  the  amount  and  type  of  each,  many  of  the 
logistical  and  training  burdens  are  alleviated. 

4.  The  Effect  on  C3  Systems 

Most  C3  systems  that  are  procured  today  and  in  the  future  will  undoubtedly 

incorporate  incremental  evolutionary  upgrades  during  their  useful  life  cycle. 

Evolutionary  Acquisition  will  be  the  strategy  used  to  accomplish  this.  Brigadier  General 

Edward  Hirsch7,  USA  (Ret.),  wrote  in  an  article  in  Signal  magazine: 

Evolutionary  Acquisition  is  not  a  cure-all  for  the  real  or  perceived  ills  of  the  U. 

S.  acquisition  process;  but  it  does  hold  some  promise  to  help  field  command  and 
control  systems  sooner,  at  lower  cost  and  with  higher  user  satisfaction  than  other 
approaches.  [Ref.  12:p.  23] 


7  Director,  Center  for  Acquisition  Management  Policy,  Defense  Systems  Management 
College  at  the  time  of  publication  of  the  article. 
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Evolutionary  Acquisition  has  gained  wide  recognition  as  a  strategy  that 


provides  the  flexibility  necessary  to  adapt  evolving  C3  systems. 


E.  THE  OPEN  ARCHITECTURE  ENVIRONMENT 

1.  Overview 

A  current  approach  to  eliminating  the  problems  of  incompatibility,  while 
transcending  the  problems  of  centralized  systems,  is  called  the  "open  systems"  approach. 
There  is  a  trend  within  the  industry  to  develop  products  according  to  government, 
international,  and  industry  standards.  Users,  vendors,  and  government  standards 
organizations  are  encouraging  the  development  of  open  system  architectures.  According 
to  the  International  Organization  for  Standardization  and  the  International  Electrotechnical 
Committee  (ISO/IEC),  an  open  system  is  a  system  that  complies  with  the  requirements 
of  a  given  set  of  universally  accepted  standards  for  communication  and  interacting  with 
other  open  systems.  Advantages  of  adopting  open  system  architecture  standards  are  the 
following: 

1.  Increased  competition  results  from  the  variety  of  vendors  manufacturing 
products  to  meet  the  specified  standards. 

2.  Interoperability  and  portability  are  attainable  only  with  systems  using  the  same 
standards. 

3.  Open  systems  support  a  multivendor  environment,  which  reduces  the  chance  that 
the  government  will  be  dependent  on  a  single  contractor. 

Although  a  potential  logistics  risk  is  created  by  a  multivendor  environment,  this  can  be 
managed  by  requiring  that  all  products  purchased  be  contained  on  a  list  previously 
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established  by  the  government.  [Ref.  18:p.  2]  The  principle  disadvantages  of  using 
standards  are: 


1 .  A  standard  tends  to  freeze  the  technology.  By  the  time  a  standard  is  developed, 
subjected  to  review  and  compromise,  and  promulgated,  more  efficient 
techniques  are  possible. 

2.  There  are  multiple  standards  for  the  same  thing.  This  is  not  a  disadvantage  of 
standards  per  se,  but  of  the  way  things  are  currently  done.  Fortunately,  in 
recent  years,  the  various  standards-making  organizations  have  begun  to 
cooperate  more  closely.  Nevertheless,  there  are  still  areas  where  multiple 
conflicting  standards  exist.  [Ref.  19 :p.  18] 


2.  The  Effect  on  C3  Systems 

Currently  evolving  open  system  standards  include  POSIX8  interfaces, 
GOSIP9  data  communication  protocols,  the  ADA  programming  language,  SQL  data 
management  systems,  X-Windows  User  interfaces,  Motif  Graphic  services,  and  X.400 
message  handling  systems.  [Ref.  8:p.  3-61]  Since  these  standards  are  still  evolving,  C3 
systems  developed  in  an  open  systems  architecture  today  should  have  an  integration  plan 
that  allows  for  the  smooth  incoiporation  of  future  evolving  standards. 

The  use  of  open  systems  standards  such  as  GOSIP  is  now  a  federal 
information-processing  standard  (FIPS)  and  is  mandatory  for  use  on  government 
procurements  [Ref.  19:p.  27],  C3  systems  that  are  developed  using  open  system 
architectures  reduce  system  integration  costs;  increase  freedom  of  choice  in  selecting 


8  Portable  Operating  System  Interface;  X  denotes  its  UNIX  origin. 

9  Government  Open  System  Interconnection  Profile. 
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vendors;  protect  investments  in  software,  data,  and  people;  and  enhance  availability, 
quality,  and  variety  of  complementary  products.  [Ref.  20] 

F.  CURRENT  C3  SYSTEM  EVALUATION  FRAMEWORKS 

This  section  will  discuss  some  of  current  frameworks  used  today  for  evaluating  C3 
systems. 

1.  The  Mission-Oriented  Approach  (MO A) 

The  Mission-Oriented  Approach  is  a  framework  for  formulating  requirements 
in  order  to  achieve  the  desired  balance  among  mission  support,  technical  capability,  and 
resources.  This  approach  systemically  and  consistently  addresses  four  interrelated 
questions  (see  Figure  3). 

First,  it  addresses  the  question  "What  are  we  trying  to  achieve  operationally?" 
This  question  must  be  answered  by  high-level  decision  makers  in  the  context  of  relevant 
policy  and  political-military  considerations.  The  response  is  generally  cast  in  terms  of 
a  set  of  strategic  capability  objectives  for  employing  forces.  These  force  capability 
objectives  provide  the  standards  against  which  the  capabilities  of  existing  and  proposed 
packages  of  information  systems  can  be  measured. 

The  second  phase  of  the  requirements  process  addresses  the  question:  "How 
should  we  perform  the  mission  operationally?"  This  question  must  be  addressed  by 
operational  personnel  who  must  formulate  concepts  of  operations  at  multiple  levels: 
strategic  (e.g.,  the  concept  of  forward  defense),  operational  (e.g.,  mix  and  emphasis 
among  missions),  and  functional  capability  (e.g.,  ability  to  sense,  assess,  plan,  and  direct 
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to  achieve  mission  goals).  The  capability  objectives  for  each  of  these  levels  must  be 
derived  self-consistently,  beginning  with  specified  strategic  capability  levels,  based  on 
likely  adversarial  operations,  friendly  concepts  of  operation,  and  environmental  factors. 

The  third  phase  of  the  requirements  process  addresses  the  question:  "What 
technical  capability  is  needed  to  support  the  operation?"  This  phase  should  employ 
technical  personnel  to  translate  the  operational  capability  objective  levels  into  the  desired 
technical  attributes  of  the  information  systems  needed  to  implement  those  capability 
levels.  These  technical  capability  objectives  are  derived  using  the  existing  and  projected 
technical  characteristics  of  adversary  forces,  friendly  forces,  and  environmental  factors. 

The  fourth  phase  of  the  requirements  process  addresses  the  question:  "How 
is  the  technical  job  to  be  accomplished?"  As  a  foundation  for  this  question,  technical 
deviations  are  identified  be  comparing  the  technical  capabilities  of  existing  and 
programmed  information  systems  to  the  time  varying  technical  capability  objectives 
identified  in  the  prior  phase.  Based  on  those  deviations,  technical  and  programmatic 
personnel  can  formulate  technical  requirements  that  are  consistent  with  assumptions  on 
available  resources  and  schedule.  If  these  communities  are  to  perform  this  task  credibly, 
it  is  critical  that  they  be  cognizant  of  the  unique  characteristics  of  information  systems. 
These  systems  are  characterized  by  internal  and  external  interfaces  that  are  complex, 
frequently  changing,  and  at  multiple  organizational  levels.  Humans  are  integral  parts  of 
these  systems  and  their  interfaces  with  one  another  and  the  machines  are  highly 
interactive,  complex,  and  changing.  The  technology  that  underlies  these  systems  (e.g., 
computers,  communications,  displays)  is  undergoing  revolutionary  change  and  emerging 
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systems  are  very  software  intensive.  Thus  the  technical  and  programmatic  communities 
face  the  challenging  task  of  formulating  technical  requirements  that  balance  technological 
risk  and  obsolescence.  [Ref.  21:pp.  119-128] 


After  initial  answers  to  these  four  questions  have  been  developed  it  is 
important  to  iterate  through  the  framework.  This  iteration  is  needed  to  identify  and 
resolve  issues  that  require  additional  analysis  across  communities  (e.g.,  interaction 
between  the  operational  and  technical  communities)  and  within  communities  (e.g., 
technical  tradeoffs  between  risk  and  potential  obsolescence).  [Ref.  22:pp.  2-5] 

The  Mission-Oriented  Approach  is  an  attractive  candidate  for  formulating  C3 
system  requirements  in  an  evolutionary  environment.  A  variation  of  this  approach  has 
been  successfully  used  by  U.S.  Pacific  Command  (USPACOM)  to  help  identify  and 
define  C3I  capabilities  and  systems  that  their  warfighters  need  to  meet  USPACOM 
mission  responsibilities.  [Ref.  23] 

While  the  Mission-Oriented  Approach  is  well  suited  for  requirements 
determination,  it  is  not  particularly  well  suited  for  the  evaluation  of  alternative  C3 
systems,  which  is  the  focus  of  this  thesis.  But,  the  approach  could  be  used  to  verify  or 
validate  current  and  future  C3  system  requirements. 

2.  The  Modular  Command  and  Control  Evaluation  Structure  (MCES) 

The  Modular  Command  and  Control  Evaluation  Structure  (MCES)  is  a 
general  approach  to  evaluating  C3  systems  which  has  been  successfully  applied  to  a 
number  of  issues  concerning  C3  system  planning,  acquisition,  testing  and  operation.  [Ref. 
24]  It  augments  traditional  analysis  by  providing  a  series  of  seven  steps  or  modules  to 
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evaluate  alternative  C3  systems  and  architectures.  These  modules  guide  analysts  who 
might  otherwise  focus  prematurely  on  the  quantitative  model  rather  than  the  problem 
definition  and  the  specific  measures  needed  to  discriminate  between  alternatives.  The 
seven  steps  of  the  MCES  are  briefly  described  below  including  the  product  of  each 
module. 

The  MCES  begins  by  identifying  the  objective  of  a  particular  application. 
This  leads  to  a  formal  problem  statement.  The  second  step  is  to  bound  the  C3  system 
involved,  by  producing  a  complete  list  of  system  elements  at  several  levels.  The  third 
step  is  building  a  dynamic  framework  that  identifies  the  relevant  C3  process-a  set  of 
functions.  The  fourth  step  combines  the  results  of  steps  two  and  three  by  integrating  the 
system  elements  and  the  process  functions  into  a  model  or  representation  of  the  C3 
system.  The  product  of  this  module  is  at  least  a  complete  descriptive  conceptual  model 
and  sometimes  a  complete  mathematical  model.  The  next  (fifth)  step  is  to  specifically 
identify  measures  of  performance,  effectiveness  and  force  effectiveness  at  the 
corresponding  levels  of  the  C3  system  and  function.  The  sixth  step  is  to  generate  results 
or  values  for  these  measures  by  testing,  simulation,  computational  modeling  or  subjective 
evaluation.  Finally,  the  various  measures  are  aggregated  and  interpreted  in  the  last  step. 
The  seven  steps  of  the  MCES  are  performed  iteratively  with  the  decision  maker  as  shown 
in  Figure  4. 

In  an  area  such  as  C\  standard  language  and  paradigms  are  difficult  but 
necessary.  The  MCES  was  developed  by  a  team  of  experts  from  industry,  government 
and  academia  and  was  endorsed  by  the  Military  Operations  Research  Society.  It  presents 
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Figure  4:  Modular  Command  and  Control  Evaluation  Structure 


difficult  concepts  in  a  standardized  way  that  is  easily  absorbed  by  both  new  practitioners 
and  managers.  MCES  has  potential  for  reducing  mis-understandings  of  the  purpose  and 
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mis-applicability  of  analytical  results.  This  is  important  when  issues  of  great  diversity 
of  nature,  size  and  level  of  detail  are  being  considered.  Standardization  of  analytical 
procedure  can  be  advantageous  if  based  on  a  comprehensive  and  rigorous  methodology 
such  as  MCES.  The  MCES  can  be  used  for  studies  ranging  from  the  quick  conceptual 
level  to  the  complete  quantitative  study.  [Ref.  25:pp.  1-3] 

The  MCES  offers  a  comprehensive  framework  for  developing  robust 
measures  for  complex  systems,  but  it  doesn’t  provide  specific  guidance  on  evaluating 
systems  that  will  change  over  time.  An  interesting  similarity  exists  between  the  Mission- 
Oriented  Approach  and  the  Modular  Command  and  Control  Structure.  Note  that  the  first 
two  questions  of  the  MOA  and  module  three  of  the  MCES  both  deal  with  C3  functions. 
Also,  the  second  two  questions  of  the  MOA  and  module  four  of  the  MCES  deal  with  C3 
components  or  capabilities  to  support  those  C3  functions. 

3.  The  Current  COEA  Evaluation  Framework 

The  following  sections  will  present  the  methodology  used  by  the  Cost  and 
Operational  Effectiveness  Analysis  (COEA)  team  for  the  evaluation  of  the  Marine  Corp's 
TCO  program  discussed  in  Chapter  I. 

a.  Approach 

Each  alternative  was  evaluated  in  three  areas:  effectiveness,  cost,  and 
risk.  The  effectiveness  evaluation  was  conducted  by  an  evaluation  team  exercising  each 
of  the  alternative  systems  in  a  laboratory  environment.  The  cost  evaluation  was 
conducted  by  collecting  cost  data  from  developers;  the  TCO  program  office;  Marine 
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Corps  Tactical  Systems  Support  Activity  (MCTSSA);  Marine  Corps  Logistics  Base, 
Albany;  the  MTACCS  Common  Application  Support  Software  program  and  MTACCS 
Common  Hardware  Support  programs;  Marine  Corps  Operational  Test  and  Evaluation 
Activity;  civilian  vendors;  and  the  Marine  Corps  Cost  Factors  Manual.  This  data  was 
validated  and  expanded  using  the  Constructive  Cost  Model  and  the  Conversion  Cost 
Model.  Both  of  these  models  predict  software  development  costs  based  on  system  size 
and  complexity.  The  Conversion  Cost  Model  specifically  addresses  costs  associated  with 
software  conversion.  Discounted  life  cycle  costs  were  estimated  using  the  Marine  Corps 
Summary  Version  Life  Cycle  Cost  Model.  The  risk  assessment  assessed  the  technical 
and  program  risk  associated  with  modifying  each  of  the  alternatives  to  satisfy  the  TCO 
requirement. 

b.  Effectiveness  Analysis 

Evaluation  of  the  effectiveness  of  TCO  alternatives  focused  on 
determining  the  operational  effectiveness,  the  operational  suitability,  and  the  life  cycle 
supportability  of  each  alternative.  To  this  end,  measures  were  developed  to  support 
assessments  of  capability  in  each  of  these  three  areas.  Measures  of  operational 
effectiveness  assess  the  military  utility  of  each  alternative.  Measures  of  operational 
suitability  assess  how  well  each  alternative  would  operate  in  an  austere  environment 
without  adversely  impacting  mobility,  maneuverability,  or  operational  flexibility. 
Measures  of  life  cycle  supportability  assess  sustainability,  maintainability,  and  growth 
potential.  These  measures  were  based  upon  the  TCO  requirement  as  documented  in  the 
TCO  MNS.  Overall  rankings  were  assigned. 
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c.  Cost  Analysis 

Life  cycle  cost  estimates  were  developed  for  each  TCO  alternative. 
These  show  the  costs  to  satisfy  TCO  core  requirements  and  the  incremental  cost  to  satisfy 
follow-on  requirements.  Life  cycle  costs  include  research,  development,  testing,  and 
evaluation  (RDT&E);  procurement;  and  15  years  of  operations  and  support  (O&S). 
RDT&E  costs  are  associated  with  software  development,  operational  test  and  evaluation, 
system  integration  and  assembly,  and  program  management.  Procurement  costs  include 
hardware,  spares,  and  repair  parts,  commercial  software,  contractor-provided  training, 
and  first  destination  transportation.  Operations  and  support  costs  include  software  and 
hardware  maintenance,  operator  training,  and  secondary  destination  transportation. 
Estimates  were  based  on  implementation  of  MCHS  Class  B  hardware  and  MCASS 
software.  An  additional  $1,500,000  per  year  has  been  estimated  to  support  evolutionary , 
system  improvements.  The  core,  follow-on,  evolutionary  and  total  life  cycle  costs  for 
each  TCO  alternative  were  calculated.  All  costs  are  in  FY  93  constant  budget  dollars. 

d.  Risk  Analysis 

The  TCO  MNS  defines  a  two  component  requirement.  One  component 
of  the  requirement  is  for  automated  tools  to  support  operations  planning  and  execution. 
The  other  component  is  for  connectivity  across  the  battlefield  using  tactical 
communications  and  for  interoperability  with  other  C3  systems.  These  two  components 
are  interdependent,  and  each  must  be  met  to  satisfy  the  TCO  MNS.  Since 
communications  connectivity  and  interoperability  will  be  provided  through  use  of 
MCASS  modules  (and  the  Tactical  Network  Server  (TNS)/Tactical  Communications 
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Interface  Module  (TCIM)),  the  risk  associated  with  satisfying  the  connectivity  and 
interoperability  portion  of  the  requirement  is  consistent  across  alternatives.  The  risk 
associated  with  providing  the  required  automated  support  for  operations  planning  and 
execution  varies  by  alternative.  The  total  risk  associated  with  any  alternative  is  a 
function  of  the  program  risk  that  an  individual  alternative  can  not  provide  the  required 
automated  tools  and  the  risk  that  MCASS  modules  will  not  provide  the  required 
connectivity  and  interoperability.  The  total  risk  function  is  defined  as  the  maximum  of 
the  program  risk  and  the  MCASS  risk. 

e.  Trade-Offs 

The  analysis  team  then  performs  a  trade-off  analysis  between  the  base 
case  and  the  TCO  COEA  alternatives  by  analyzing  the  capability  rankings  of  each 
alternative  in  terms  of  operational  effectiveness,  operational  suitability,  and  life  cycle 
supportability;  life  cycle  costs;  and  the  risk  assessment. 

/.  Decision  Criteria 

Alternative  selection  is  based  on  system  capability  (operational 
effectiveness,  operational  suitability,  and  life  cycle  supportability);  life  cycle  cost;  and 
program  risk. 

g.  Recommendations 

The  decision  criteria  will  then  lead  to  recommendations10. 


10  '’'he  actual  recommendations  of  the  COEA  team  were  not  officially  published  at  the  time 
of  this  writing  and  are  outside  of  the  scope  of  this  thesis. 
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The  methodology  used  by  the  COEA  team  is  a  comprehensive  and 
effective  way  to  evaluate  alternative  C3  systems.  It  involves  evaluating  the  alternatives 
based  on  their  current  configurations.  Projected  costs  of  adding  some  of  the  required 
core  capabilities  to  the  alternatives  were  computed  and  used  in  the  evaluation,  but 
planned  upgrade  paths  of  the  alternatives  were  not  considered  in  the  analysis. 

G.  CONCLUSIONS 

This  chapter  presented  a  discussion  of  the  technology  initiatives  that  will  impact  C3 
systems.  The  Evolutionary  Acquisition  concept  was  introduced  and  topics  such  as  Non- 
Developmental-Items,  Commercial-Off-the-Shelf  products,  and  open  architecture 
standards  were  presented.  A  representative  sample  of  some  current  evaluation 
frameworks  were  then  discussed. 

It  is  important  that  the  procurement  environment  for  C3  systems  be  understood  by 
the  evaluators.  Important  factors  of  the  procurement  environment  that  effect  C3  systems 
include;  the  recent  increased  rate  of  technological  change,  the  mandated  use  of  the 
Evolutionary  Acquisition  concept,  the  use  of  NDI  and  COTS  products,  and  the  evolving 
open  architecture  standards.  The  following  conclusions  can  be  made  in  regard  to  the 
environment  in  which  C3  system  are  procured: 

1.  That  C3  systems  must  capitalize  on  emerging  technologies  to  remain  mission 
capable. 

2.  That  C3  systems  will  incorporate  evolutionary  upgrades  throughout  their  useful 
life  cycle. 
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3.  That  most  of  these  evolutionary  upgrades  will  be  composed  of  NDI  or  COTS 
products  that  adhere  to  "open  system"  standards. 

The  Mission-Oriented  Approach,  the  Modular  Command  and  Control  Evaluation 
Structure,  and  the  COEA  team’s  evaluation  approach  represent  the  current  state  of  C3 
systems  evaluation.  It  can  be  concluded  that  none  of  these  frameworks  or  methodologies 
specifically  deal  with  the  temporal  component  of  C3  systems.  One  of  the  most  difficult 
aspects  of  C3  systems  is  that  they  will  continually  change  over  time  (given  evolving 
technologies,  standards  and  applications).  No  framework  currently  exists  that  specifically 
deals  with  evaluating  the  upgrade  paths  of  C3  systems. 

As  discussed,  C3  system  procurements  today  can  be  viewed  as  upgrades  to  existing 
C3  systems.  Even  large  procurements  that  make  sweeping  changes  will  be  incremental 
and  evolutionary.  Therefore,  it  is  useful  to  explicitly  embrace  the  evolutionary  upgrade 
concept,  and  develop  a  framework  for  comparing  alternative  upgrade  paths  rather  than 
alternative  static  C3  systems.  The  following  chapter  presents  such  a  framework. 
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m.  A  NEW  FRAMEWORK 


A.  INTRODUCTION 

1.  Purpose  of  this  Chapter 

The  purpose  of  this  chapter  is  to  present  a  useful  framework  for  evaluating 
evolutionary  upgrade  paths  of  C3  systems.  As  discussed,  most  C3  system  procurements 
will  be  evolutionary,  and  both  existing  and  new  C3  systems  will  go  through  many 
changes  during  their  useful  life  cycle.  As  emerging  technologies  mature,  C3  systems  will 
be  incrementally  upgraded  as  soon  as  is  feasible  in  order  to  remain  as  mission  capable 
as  possible.  Procurement  alternatives  that  capture  this  temporal  effect  are  evolutionary 
upgrade  paths. 

The  framework  presented  here  is  a  functionally-oriented,  capability-based 
approach  intended  to  be  a  useful  step  by  step  method  that  produces  information  about 
alternative  evolutionary  upgrade  paths  that  is  useful  to  decision  makers.  The  level  of 
discussion  is  at  a  generic  and  sometimes  abstract  level  so  that  wide  applicability  can  be 
maintained. 

2.  The  Need  for  Effective  Evaluation 

The  procurement  of  an  extensive  C3  system  or  an  extensive  upgrade  to  an 
existing  C3  system  is  an  expensive  proposition.  A  bad  decision  now  could  cost  millions 
of  dollars  in  the  future,  therefore,  a  thorough  and  effective  evaluation  framework  is 
needed.  Chapter  II  highlighted  the  major  issues  that  effect  C3  systems  and  their 
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evaluation.  It  can  be  seen  that  just  about  all  new  C3  systems  will  be  procured  over  time, 
and  will  employ  incremental  evolutionary  upgrades  to  keep  up  with  technology.  This 
temporal  component  of  C3  systems  is  a  difficult  aspect  to  evaluate.  There  are  currently 
no  widely  accepted  methods  that  accurately  evaluate  C3  systems  based  on  their  upgrade 
paths.  This  framework  will  mainly  focus  on  this  temporal  component  and  present  a  set 
of  procedures  for  evaluating  C3  systems  by  viewing  them  as  evolutionary  paths  toward 
some  future  goal  or  target  system. 

3.  Methodology 

In  presenting  the  framework,  some  key  terms  used  in  the  explanation  of  the 
framework  will  first  be  defined.  Then,  a  step  by  step  generic  procedure  will  be 
presented  along  with  recommendations  on  the  preferred  methods  for  accomplishing  those 
steps.  The  methods  developed  in  this  framework  are  suited  for  use  with  virtually  any  C3 
system  or  subsystem. 

B.  THE  FRAMEWORK 

In  presenting  the  framework,  several  terms  are  used  that  require  definitions  so  that 
the  concepts  presented  can  be  understood  by  the  reader. 

1.  Definitions 
a.  C3  System 

A  C3  system  is  a  collection  of  equipment,  personnel,  procedures, 
facilities,  and  communications  that  provide  a  commander  the  tools  essential  for  planning, 
directing,  and  controlling  operations  of  his  assigned  forces. 
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For  the  purposes  of  this  framework,  C3  systems  can  be  viewed  as  a  collection 
of  tools  that  provide  automated  support  to  those  functions  that  commanders  have  always 
performed  (e.g.,  planning,  directing  and  controlling  his  forces).  The  focus  of  most 
acquisition  related  C3  system  evaluations  are  in  the  area  of  hardware  and/or  software 
products  that  provide  automated  support  to  C3  functions  that  support  the  warfighter. 
Therefore,  the  evaluation  problem  that  this  framework  is  tailored  to  deals  with  those 
decisions  regarding  which  hardware  and/or  software  products  to  buy  or  invest  in. 

b.  C3  Functions 

The  C3  functions  that  this  framework  will  focus  on  are  those  functions 
that  commanders  have  always  performed  (e.g.,  develop  an  Operations  Plan  or 
disseminate  an  Operations  Order).  This  is  done  so  that  the  warfighter’s  needs  remain  in 
focus.  As  discussed,  C3  systems  provide  automated  support  to  C3  functions.  For  the 
purpose  of  this  discussion,  when  the  automation  of  a  function  is  referred  to,  it  could 
either  mean  just  automated  support  to  that  function  or  the  full  automation  of  that 
function.  In  order  to  identify  the  level  of  functions  to  be  used  in  this  framework, 
functional  decompositions  may  be  required11. 

c.  Technological  Capabilities 

In  order  to  provide  automated  support  to  C3  functions,  the  system  must 
afford  a  set  of  capabilities  that  will  be  called  technological  capabilities  (e.g.,  word 
processing  capability,  interoperability  with  another  system,  digital  mapping,  etc.).  Most 

11  Functional  decompositions  will  be  explained  later  in  the  chapter. 
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capabilities  that  new  C3  systems  will  possess  are  a  product  of  some  new  technological 
advance  (e.g.,  fiber  optics,  open  systems  standards,  bubble  memory,  etc),  therefore,  they 
will  refer  to  as  technological  capabilities.  In  order  to  provide  automated  support  to  a 
function,  a  set  of  technological  capabilities  is  required.  For  example,  to  automate  the 
production  of  overlays,  technological  capabilities  such  as  pen/mouse  user  interface, 
digital  mapping,  high  resolution  display,  iconic  and  symbology  database,  and  hard  copy 
capabilities  are  just  a  few  of  the  technological  capabilities  required. 

d.  The  Target  System  Functions  and  Capabilities 

The  target  system  is  a  system  that  provides  the  desired  level  of  automated 
support  to  each  of  the  C3  functions  within  the  system  boundaries  at  some  future  planning 
horizon. 

The  target  system  functions  are  the  set  of  C3  functions  that  are  automated 
in  the  target  system,  and  the  target  system  capabilities  are  the  technological  capabilities 
required  to  provide  the  automated  support. 

The  target  system  functions  and  capabilities  will  be  displayed  in  a 
function/capability  table  so  that  the  relationship  between  them  can  be  clearly  seen. 
Figure  5  illustrates  what  this  table  will  look  like.  For  example,  refemng  to  Figure  5, 
in  order  to  automate  function  FI,  technological  capabilities  TCI  and  TC3  are  required. 

e.  Current  or  Base  System 

A  current  or  base  system  is  a  system  that  is  currently  in  use  or  one  that 
could  be  bought  today.  It  usually  only  automates  a  subset  of  the  functions  listed  in  the 
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FUNCTION/CAPABILITY  TABLE 
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Figure  5:  Capability/Function  Table 


target  system’s  function/capability  table  described  above.  In  an  evaluation,  current  or 
base  systems  are  viewed  as  alternative  base  systems.  These  alternative  base  systems  are 


those  systems  that  can  be  reasonably  expected  to  some  day  obtain  the  level  of  automation 
that  is  required  in  the  target  system. 


f.  Migratory  Systems 

Migratory  systems  are  future  upgraded  versions  of  a  particular  base 
system  and  usually  consists  of  the  base  system  plus  some  additional  technological 
capabilities.  Several  migratory  systems  could  spawn  from  a  base  system  given  different 
evolutionary  upgrade  plans. 
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g.  Viable  Upgrade  Path 

A  viable  upgrade  path  is  an  incremental  series  of  upgrades  to  a  base 
system  that  will  eventually  lead  to  a  fully  functional  target  system.  A  viable  path  is  one 
that  is  reasonable  in  terms  of  cost  and  risk  and  is  agreed  upon  by  the  operational, 
technical,  and  the  programmatic  experts.  Effective  cooperation  is  crucial  in  the 
development  of  these  viable  upgrade  paths.  Figure  6  illustrates  how  each  alternative  base 
system  could  take  different  paths  toward  achieving  the  required  target  capabilities. 


Figure  6:  Illustration  of  Viable  Paths 
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h.  Value 


The  term  value  will  be  used  to  represent  the  benefit  gained  by  a  force 
when  a  particular  function  is  provided  the  required  level  of  automated  support.  This 
added  value  or  benefit  to  the  force  due  to  the  automation  of  a  function  could  be 
measured  in  terms  of  a  Measure  of  Force  Effectiveness  (MOFE)12  or  in  terms  of  a 
relative  importance  or  weight13.  In  either  case,  a  value  or  benefit  to  the  force,  must  be 
associated  with  each  target  system  function. 

i.  Costs 

Two  types  of  costs  are  referred  to  in  the  discussion  of  the  framework. 
The  first  type  of  cost  focuses  on  procuring  a  particular  alternative  base  system  today. 
This  cost  should  be  an  estimated  life  cycle  cost  of  the  alternative  base  system  as  it  is 
configured  today.  It  should  include  the  costs  associated  with  research,  development, 
testing,  and  evaluation  (RDT&E);  procurement;  and  15  years  of  operation  and  support 
(O&S)14.  Costs  associated  with  hardware  procurement,  hardware  and  software 
integration,  system  fielding,  hardware  and  software  maintenance,  and  system  training  and 
operations  can  be  collected  from  government  organizations,  government  publications,  and 
private  industry.  All  cost  data  should  be  normalized  to  the  current  constant  budget 
dollars. 


12  For  example,  force  exchange  ratio,  number  attackers  attrited  per  unit  time,  etc. 

13  Methods  for  obtaining  relative  weights  will  be  discussed  later. 

14  The  15  year  life  was  taken  from  the  COEA  Final  Report  (Draft) 
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The  second  type  of  cost  used  in  the  framework  is  the  cost  of  adding 
technological  capabilities  to  alternative  base  systems.  The  same  kind  of  life  cycle  costs 
as  discussed  above  should  be  used,  but  it  should  focus  only  on  the  costs  associated  with 
a  particular  technological  capability  and  its  integration  into  an  existing  system.  The  cost 
of  adding  a  technological  capability  only  needs  to  be  normalized  to  the  year  in  which  it 
is  projected  to  be  added  to  a  system.  Methods  for  discounting  these  costs  will  be 
presented  later. 

2.  The  Framework 

In  order  to  evaluate  alternative  systems  that  will  change  over  time,  the  ideas 
of  a  current  or  base  system,  migratory  systems,  and  a  target  system  help  frame  the 
problem.  The  current  system  is  the  system  currently  in  use  or  one  that  could  be  bought 
today  to  fulfil  some  mission  need.  All  systems  or  subsystems  in  place  today  will  some 
day  either  become  technologically  obsolete  or  no  longer  meet  the  needs  of  the  user. 
When  the  time  comes  to  replace  or  upgrade  that  system  or  subsystem,  decisions  must  be 
made  as  to  how  to  proceed.  This  framework  presents  a  method  that  could  be  useful  to 
decision  makers  in  making  that  decision.  The  framework  contains  four  top  level  steps: 

1.  Define  target  system  functions  and  capabilities. 

2.  Define  all  viable  upgrade  paths  from  each  alternative  base  system  to  the  target 
system;  each  path  becomes  a  candidate  path. 

3.  Develop  a  discounted  value  and  a  discounted  cost  for  each  candidate  path. 

4.  Select  the  candidate  path  that  maximizes  value  subject  to  a  stated  cost,  resource, 
ai  d  risk  constraints. 
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A  brief  summary  of  the  steps  shown  in  Figure  7  follows. 


Figure  7:  The  Steps  of  the  New  Framework 

The  first  step  of  the  framework  begins  by  defining  the  target  system  in  terms 
of  the  functions  it  should  automate  and  the  technological  capabilities  required  to  automate 
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each  of  those  functions.  The  value  of  each  of  those  functions  is  then  determined.  The 


output  of  this  step  is  a  table  highlighting  the  relationships  between  the  target  system’s 
technological  capabilities  and  the  functions  it  must  automate  along  with  the  value  of  each 
function.  The  second  step  of  the  framework  begins  by  identifying  all  of  the  alternative 
base  systems  in  terms  of  the  technological  capabilities  they  possess.  All  viable  paths  to 
the  target  system  that  spawn  from  each  alternative  are  then  determined.  The  output  of 
this  step  is  an  enumeration  of  all  viable  candidate  paths.  The  third  step  of  the  framework 
involves  assigning  functionally  derived  values  and  capability  derived  costs  to  each 
candidate  path  at  discrete  time  intervals.  These  values  and  costs  are  then  discounted  to 
the  present.  The  output  of  this  step  is  a  discounted  value  and  cost  associated  with  each 
candidate  path.  The  last  step  of  the  framework  involves  filtering  out  the  candidate  paths 
that  do  not  meet  the  cost  constraint  and  then  picking  the  candidate  path  that  has  the 
greatest  value.  This  should  result  in  the  candidate  path  that  provides  the  greatest  value 
to  the  force  given  a  particular  cost  constraint. 

The  above  steps  of  the  framework  are  expanded  upon  in  the  following 

sections. 

a.  Define  Target  System  Functions  and  Capabilities 
Figure  8  illustrates  this  step. 

(1)  Functions  and  Capabilities.  In  the  acquisition  world,  descriptions 
of  target  systems  are  easily  found  in  documents  like  the  Mission  Need  Statement  (MNS) 
and  the  Operational  Requirements  Document  (ORD).  These  documents  highlight  needs, 
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Figure  8:  The  New  Framework  -  Step  1:  Define  Target  System 


requirements,  and  constraints  for  a  given  system.  In  the  case  of  C3  systems,  from  the 
requirements,  a  list  of  functions  that  require  automated  support  can  be  derived.  This 
automated  support  is  provided  via  capabilities.  The  functions  derived  from  the 
requirements  are  normally  those  that  commanders  and  their  staffs  have  always  done 
(e.g.,  prepare  an  operations  order  and  disseminate  it,  develop  courses  of  action,  decide 
on  course  of  action,  direct  his  forces,  etc.).  The  functions15  should  be  chosen  at  a  level 


15  At  this  point,  the  author  will  assume  that  the  functions  can  be  automated  independentl> 
realizing  that  interdependence  really  exists. 
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that  will  allow  a  manageable  sized  list  of  required  technological  capabilities  to  be 
defined.  Functional  decompositions  are  usually  required.  Figure  9  illustrates  what  a 
simple  generic  functional  decomposition  looks  like. 


FUNCTIONAL  DECOMPOSITION 


FI 

_ i  1 

] 

Fit 

F1.2 

FI  3 

Figure  9:  Example  of  Generic  Functional  Decomposition 

Once  the  functions  are  identified,  the  technological  capabilities  required  to  provide  the 
required  automated  support  can  be  determined.  Through  elicitation  of  technical  and 
operational  experts,  a  list  of  the  capabilities  required  to  automate  each  function  at  the 
required  level  can  be  obtained.  It  should  be  realized  here  that  some  of  the  capabilities 
in  this  list  may  not  be  available  yet,  given  the  current  state  of  technology. 

After  completing  the  above  procedure,  a  function/capability  table  can  be 
constructed  that  shows  the  relationships  between  the  functions  and  the  technological 
capabilities.  Table  I  illustrates  what  this  table  looks  like.  In  the  column  that  corresponds 
to  an  operational  function,  an  X  is  placed  in  the  boxes  corresponding  to  the  rows  of  the 
technological  capabilities  required  to  automate  that  function.  A  function  cannot  be 
automated  at  the  required  level  unless  all  the  technological  capabilities  with  an  X  in  that 
function’s  column  are  provided  by  the  system.  For  example,  from  Table  I,  function  FI 
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Table  I:  FUNCTION/CAPABILITY  TABLE 


Technological 

Capabilities 

Operational  Functions 

FI 

F2 

.  .  . 

FN 

TCI 

X 

X 

TC2 

X 

X 

X 

.  .  . 

TCn 

X 

cannot  be  adequately  supported  with  the  desired  level  of  automated  support  unless  the 
system  possesses  technological  capabilities  TCI  and  TC2. 

(2)  Value  of  C?  Functions.  Once  the  relationship  between  target  system 
functions  and  capabilities  is  known,  the  next  part  of  this  first  step  is  to  determine  the 
value  of  each  function.  The  goal  here  is  to  assign  a  value  or  benefit  added  to  the  overall 
force  when  a  particular  function  is  automated. 

One  method  to  accomplish  this  would  be  to  design  an  experiment 
or  construct  a  model  that  would  allow  the  assessment  of  the  effect  on  overall  force 
effectiveness  given  that  a  particular  function  is  automated.  Runs  of  the  experiment  or 
model  could  be  made  when  the  function  is  performed  without  automated  support  and 
then  again  with  the  automated  support16.  The  outcomes  of  each  case  could  be  compared 
and  a  MOFE  assigned  as  the  value  of  the  function.  This  method  would  be  done  for  all 


16  A  typical  question  that  could  be  answered  is,  "What  effect  does  automating  overlays  have 
on  the  overall  effectiveness  of  the  force?" 
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of  the  target  system  functions.  But,  it  obviously  would  require  a  substantial  expenditure 
of  time  and  money,  both  of  which  are  usually  limited. 

Another  method  requiring  less  time  and  money  would  be  to  elicit 
relative  values17  or  the  importance  of  each  function  from  experienced  operational 
experts.  The  idea  is  to  elicit  from  the  experienced  experts  the  relative  importance  to  the 
operational  force  of  automating  each  target  system  function.  Various  methods  of 
elicitation  include  closed  questions,  open  questions,  brainstorming  guided  brainstorming, 
and  group  consensus.  [Ref.  26] 

Other  methods  such  as  the  Analytic  Hierarchy  Process  (AHP)  or 
the  Simple  Multi-Attribute  Rating  Technique  (SMART)  can  also  provide  tools  to  aid  in 
obtaining  the  relative  value  or  weight  of  each  function  to  the  force.  [Ref.  27]  These  two 
methods  structure  the  problem  as  a  hierarchy  which  serves  as  a  useful  aid  to 
understanding  problems  and  fostering  discussion  about  them.  The  process  can  reveal 
issues  which  have  not  previously  been  explicitly  stated.  AHP  utilizes  pair-wise 
comparisons  of  attributes18,  where  as  SMART  elicited  values  on  a  0-100  scale  for  each 
attribute.  The  process  used  by  both  is  easy  to  understand  and  decision  makers  have  been 

17  The  term  relative  value  or  weight  has,  at  times,  not  been  well  received  by  professionals 
in  the  acquisition  and  operational  fields  because  arguments  among  steering  committee  members 
have  lasted  for  hours  on  what  weights  to  assign.  This  should  not  be  viewed  as  bad,  in  fact,  this 
is  one  of  the  advantages  of  this  kind  of  method  because  it  forces  decision  makers  to  deal  with 
difficult  issues  that  may  have  not  been  explicitly  stated  before. 

18  Attributes,  in  the  case  of  determining  relative  values  of  functions,  would  refer  to  low 
level  functions  that  result  from  the  decomposition  of  higher  level  functions. 


comfortable  with  it19.  Applying  either  of  these  methods  would  result  in  a  list  of  the 
relative  values  or  weights  for  each  function.  These  methods  emphasize  the  point  that  the 
value  of  a  system  (through  automation  of  functions)  is  what  it  does  for  the  user.  This 
value  can  be  estimated  via  the  user’s  perception  of  the  relative  importance  of  the  various 
areas  in  which  the  user  benefits  from  the  system.  [Ref  28] 

Table  II  illustrates  what  the  results  of  this  step  should  produce.  In 
summary,  the  first  step  of  this  framework  results  in  defining  the  target  system  in  terms 
of  the  C3  functions  it  supports  and  the  technological  capabilities  required  to  provide 
automated  support  to  those  functions.  Furthermore,  the  value  of  each  function  is 

Table  H:  FUNCTION/CAPABILITY  TABLE  FOR  THE  TARGET  SYSTEM 


Technological 

Capabilities 

Operational  Functions 

FI  VI 

F2  V2 

.  .  . 

FN  VN 

TCI 

X 

X 

TC2 

X 

X 

X 

•  •  • 

TCn 

X 

determined  in  terms  of  a  MOFE  or  by  a  weight  or  relative  importance  to  the  force. 
The  added  VI,  V2,  ...  ,  VN  in  Table  II  represent  the  value  of  that  particular  function. 


19  Case  studies  can  be  found  in  Reference  27. 
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This  table  provides  the  information  needed  in  subsequent  steps  of  the  framework.  The 
next  step  involves  defining  candidate  paths. 

b.  Define  Candidate  Paths 

Figure  10  illustrates  this  step.  The  step  of  defining  candidate  paths 
requires  two  tasks,  first  the  alternative  base  systems  are  determined  and  then  the 
candidate  paths  that  spawn  from  these  altemadve  base  systems  are  enumerated.  The  goal 
of  this  step  is  to  come  up  with  a  list  of  the  viable  (or  reasonable)  candidate  paths  that  will 
lead  to  obtaining  the  capabilities  established  in  the  definition  of  the  target  system 
functions  and  capabilities  from  step  one. 

This  step  begins  by  identifying  the  alternative  base  systems  that  will  be 
considered  in  the  evaluation.  These  alternatives  should  be  systems  that  preferably 
already  meet  some  of  the  requirements  of  the  target  system.  The  alternative  base 
systems  should  be  chosen  by  the  experts  with  the  target  system  in  mind.  The  concept 
is  that  each  chosen  alternative  base  system  could  someday  fulfill  all  the  requirements  of 
the  target  system  by  incrementally  adding  future  technological  capabilities.  Initially,  each 
alternative  base  system  will  possess  a  set  or  vector  of  technological  capabilities,  TC. 
Let  time  be  discrete  (t  =  1,...,T)  where  T  is  the  planning  horizon,  then  at  each  date  t, 
there  is  a  vector  of  technological  capabilities  TC,  generated  by  each  alternative  system. 
Each  alternative  system  will  evolve  over  time  given  that  there  is  technological  change 
over  time  (and  hence  automation  opportunities).  Several  viable  paths  could  spawn  from 
each  alternative  system.  Each  one  of  these  viable  paths  will  become  a  candidate  path  and 
could  be  developed  by  creating  a  specific  scenario  of  technological  change  and 
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Figure  10:  The  New  Framework  -  Step  2:  Defining  Candidate  Paths 


automation  for  its  base  system.  Each  candidate  path  should  satisfy  the  current  cost, 
resource,  and  risk  constraints. 

The  Figure  1 1  illustrates  that  each  particular  alternative  base  system  will 
migrate  towards  the  capability  of  the  target  system  by  following  one  of  several  reasonable 
and  viable  paths  of  upgrades.  Each  candidate  path  begins  at  an  alternative  system.  As 
technological  capabilities  are  added,  migratory  systems  are  realized  until  finally  the 
capabilities  of  the  target  system  are  obtained.  At  each  date  t,  each  candidate  path  has 
associated  with  it  a  new  vector  or  set  of  technological  capabilities.  This  list  of 
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capabilities  may  succeed  in  providing  the  capabilities  required  to  provide  automated 
support  to  more  target  system  functions.  Therefore,  each  candidate  path  contains  a 
changing  list  of  technological  capabilities  and  a  changing  list  of  functions  that  it  can 
provide  the  required  automated  support  to.  The  next  step  of  the  framework  involves 
determining  the  overall  value  and  cost  of  each  candidate  path. 

c.  Get  Values  and  Costs 

Figure  12  illustrates  this  step.  The  goal  of  this  step  is  to  derive  a  single 
overall  discounted  value  and  a  single  overall  discounted  cost  for  each  candidate  path 
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constructed  in  step  two  of  the  framework.  Methods  for  determining  the  discounted 
values  and  costs  will  be  presented  in  the  following  sections. 


DEVELOP  VALUE  AND  COST 


•  EACH  FUNCTION  PROVIDED  HAS  A  VALUE 

•  EACH  CAPABILITY  HAS  A  COST 

•  CREATE  VALUE  AND  COST  VECTORS 

FOR  EACH  CANDIDATE  PATH 

•  DISCOUNT  THE  VALUES  AND  COSTS 

•  ADD  ALL  DISCOUNTED  VALUES  AND  COSTS 

FOR  EACH  CANDIDATE  PATH 


CANDIDATE  PATH 
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Figure  12:  The  New  Framework  -  Step  3:  Develop  Value  and  Cost 


(1)  Value.  Since  the  value  of  each  function  defined  in  the  target 
system  is  now  know  from  step  one,  the  overall  value  of  any  candidate  path  depends  on 
the  functions  it  succeeds  in  automating  and  when  they  are  automated.  Any  set  or  vector 
of  technological  capabilities,  TC,  can  be  easily  assigned  a  value  by  adding  the  values  of 
the  functions  that  the  set  of  capabilities  automates.  Since  each  candidate  path  is  actually 
a  time  series  of  TC  vectors,  at  each  time  step  there  is  a  TC,  (vector  of  technological 
capabilities  at  time  t).  Each  successive  TC,  vector  of  a  candidate  path  may  provide  the 
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capability  to  automate  additional  functions  by  the  addition  of  more  technological 
capabilities.  So  each  candidate  path  can  be  viewed  as  a  time  series  of  upgrades 
(additional  technological  capabilities  added)  that  incrementally  automate  additional 
functions  until  all  the  functions  of  the  target  system  are  given  the  required  level  of 
automation  support  (from  the  definition  of  the  target  system  in  step  one). 

If  each  candidate  path  simply  receives  the  value  of  a  function  when 
it  succeeds  in  automating  it,  all  paths  will  receive  the  same  value  since  all  candidate 


DISCOUNTING  OF  FUNCTIONS 


YEAR  IN  WHICH  SYSTEM  GAINS  FUNCTION 


Figure  13:  A  Way  to  Discount  the  Value  of  a  Function 
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paths  will  eventually  automate  all  of  the  target  system  functions.  Clearly,  it  is  more 
useful  to  the  warfighter  to  provide  automated  support  today  rather  that  several  years  in 
the  future.  Measures  used  to  compare  paths  should  reflect  this  difference.  Therefore, 
in  order  to  make  this  a  meaningful  measure,  a  method  of  discounting  the  value  of 
functions  must  be  used.  In  order  to  develop  a  discounted  value  for  the  candidate  paths, 
a  value  versus  time  curve  for  each  function  is  needed.  It  is  generally  agreed  that  the 
sooner  a  system  can  automate  a  particular  function,  the  more  valuable  that  system  will 
be  to  the  user  in  terms  of  that  function.  That  is,  a  candidate  path  that  automates  a 
particular  function  earlier  than  another  should  receive  more  value  for  automating  that 
function  sooner.  Therefore,  for  each  function,  a  kind  of  "utility"  curve  could  be 
developed  like  that  in  Figure  1320.  The  lower  curve  could  be  used  for  functions  that 
are  more  critical  to  the  users.  That  is,  if  two  candidate  paths  are  being  compared,  the 
path  that  automates  a  function  (utilizing  the  lower  curve  for  its  discounting)  the  soonest, 
will  receive  a  far  greater  value  than  a  path  that  automated  the  function  later.  Where  as, 
if  the  upper  curve  was  used,  the  difference  in  value  between  two  paths  would  be  less. 

For  ease  of  calculations,  the  simplest  case  would  be  that  at  the  present  time  (t  =  0),  the 
full  value  of  a  function  is  given  if  the  vector  of  technological  capabilities,  TC0,  present 
in  the  alternative  base  system  for  a  candidate  path  has  all  the  capabilities  required  to 
automate  that  function.  If,  on  the  other  hand,  the  function  is  not  automated  until  the 
planning  horizon,  say  ten  years  (t  =  10),  by  the  vector  TC10,  some  residual  fraction 

20  A  thorough  discussion  of  utility  theory  and  its  relationship  to  decisions  under  risk  is 
contained  in  Chapter  11  of  Reference  29. 
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(one-half  is  chosen  for  the  illustration)  of  the  value  to  the  force  of  automating  that 
function  would  be  given  to  the  candidate  path. 

How  this  "utility  curve"  of  the  value  of  the  function  in  Figure  13  behaves 
between  the  present  time  and  the  planning  horizon  is  a  function  of  the  temporal 
importance  or  the  time  criticality  of  automating  that  function  as  discussed  above. 

The  discounted  values,  denoted  DV,  for  each  function  are  derived 
from  each  function’s  utility  curve  and  are  a  function  of  the  time  the  system  received  the 
capability  to  automate  that  function.  The  following  equation  would  be  used  to  calculate 
the  discounted  value  of  a  function  if  the  linear  relation  in  Figure  13  was  chosen: 


DV^V-t 


.Zi 

20 


(1) 


Where  DV;  is  the  discounted  value  of  the  i111  function,  V,  is  the 
value  of  the  i*  function  at  t  =  0,  and  t  is  the  year  or  time  period  that  the  candidate  path 
successfully  automates  the  function  i. 

The  overall  discounted  value,  ODV,  of  a  particular  candidate  path 
would  then  be  the  sum  of  the  discounted  values  of  each  function21.  To  find  the  overall 
discounted  value  of  the  candidate  path,  the  individual  discounted  values  of  each  function 
are  simply  added.  The  following  equation  will  be  used: 


21  Still  assuming  that  independence  exists  between  functions. 
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(2) 


N 

ODV^Y,  DVi 

i- 1 

Where  ODV  is  the  overall  discounted  value  of  the  candidate  path,  i  is  a 
counter  for  the  individual  functions,  N  is  the  total  number  of  functions,  and  DV;  is  the 
discounted  value  of  the  i*  function. 

This  concept  of  functionally  derived  values  can  provide  valuable  insight  into 
prioritizing  the  more  important  technological  capabilities  for  future  acquisition  decisions. 
Candidate  paths  that  receive  relatively  high  values  will  undoubtedly  benefit  the  user  more 
than  one  with  a  lower  value  because  the  more  important  functions  are  automated  sooner. 

(2)  Cost.  Costs  used  in  this  framework  are  derived  from  capabilities 
and  are  those  discussed  in  Section  2,  Paragraph  i.  They  consist  of  the  cost  of  the 
alternate  base  system  if  bought  today  and  the  cost  of  adding  a  particular  technological 
capability  in  the  future  to  a  given  base  system.  Costs  of  adding  a  particular  technological 
capability  may  be  different  for  each  alternative  base  system  because  each  system  may 
require  different  combinations  of  hardware  and/or  software  to  provide  the  required  level 
of  automation  depending  on  the  current  configuration  of  the  base  system.  As  discussed 
earlier,  the  costs  should  include  the  costs  associated  with  research,  development,  testing, 
and  evaluation  (RDT&E);  procurement;  and  15  years  of  operation  and  support  ( O&S )". 
Costs  associated  with  hardware  procurement,  hardware  and  software  integration,  system 
fielding,  hardware  and  software  maintenance,  and  system  training  and  operations  can  be 


22  The  15  year  O&S  time  frame  was  used  in  the  COEA  Final  Report  (Draft).  [Ref.  8] 
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collected  from  government  organizations,  government  publications,  and  private  industry. 
The  cost  of  the  alternative  base  system  should  be  normalized  to  the  current  constant 
budget  dollars,  but  the  cost  of  adding  the  technological  capabilities  should  be  normalized 
to  the  year  in  which  they  are  added  to  a  candidate  path. 

Discounted  costs  of  adding  technological  capabilities  are  computed 
using  the  standard  discounting  function: 


DC<  = 


(3) 


[  (l+r)yj  J 

Where  DCj  is  the  discounted  cost  of  adding  the  j*  technological 
capability,  r  is  the  discounting  factor  or  interest  rate,  y  is  the  year  or  time  period,  and 
Cj  is  the  cost  of  adding  the  j*  technological  capability  to  the  system. 

To  calculate  the  overall  discounted  cost  of  the  candidate  path,  the 
initial  cost  of  the  alternative  base  system  is  added  to  the  discounted  cost  of  each 
technological  capability  that  is  added  to  the  candidate  path.  The  following  equation  is 
used  to  compute  the  overall  discounted  cost  of  a  candidate  path: 


M 

ODC=IC  +]T)  DCj  W 

o 

Where  ODC  is  the  overall  discounted  cost  of  a  candidate  path,  ICj 
is  the  initial  cost  of  buying  the  alternative  base  system,  M  is  the  total  number  of 
technological  capabilities  that  are  added  to  a  candidate  path,  and  DC,  is  the  discounted 
cost  of  adding  the  j*  technological  capability.  Figure  14  illustrates  these  calculations. 
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Figure  14:  The  Discounting  of  Values  and  Costs 

The  procedure  for  finding  the  overall  discounted  value  and  cost  of  a 
candidate  path  is  straight  forward.  The  first  step  involves  determining  when  (or  at  which 
time  periods)  the  candidate  path  will  succeed  in  automating  the  functions  of  the  target 
system.  The  second  step  requires  the  use  of  Equation  (1)  to  compute  the  discounted 
value  of  each  of  the  functions.  The  third  step  uses  Equation  (3)  to  calculate  the 
discounted  costs  of  the  technological  capabilities  that  are  added  to  the  system.  The  fourth 
and  fifth  steps  use  Equations  (2)  and  (4)  to  compute  the  overall  discounted  value  and  cost 
of  the  candidate  path. 
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The  output  of  the  above  calculations  is  a  single  overall  discounted  value 
and  a  single  overall  discounted  cost  for  each  candidate  path.  The  next  step  discusses  how 
to  select  the  best  candidate  path  given  this  data. 

d.  Select  Candidate  Path 

Figure  15  illustrates  the  final  step.  The  above  procedures  will  result  in 
a  list  of  the  discounted  values  and  costs  for  each  candidate  path.  A  simple,  but  common 
problem  statement  is  to  maximize  value  subject  to  cost,  resource,  and  risk  constraints. 
The  rule  or  problem  is  stated  as: 

Maximize:  Value 

Subject  to:  •  Cost 

•  Resource 

•  Risk 

This  would  result  in  the  candidate  path  that  provides  the  user  with  the  best 
possible  benefit  within  the  established  cost,  resource,  and  risk  thresholds.  The  method 
for  selecting  the  best  candidate  path  under  this  rule  is  to  disregard  the  candidate  paths 
that  do  not  meet  one  or  more  of  the  constraints.  Then  select  from  the  remaining 
candidate  paths  the  one  with  the  highest  value. 
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Figure  15:  The  New  Framework  -  Step  4:  Select  Best  Candidate  Path 


3.  Conclusions 

In  the  above  discussion,  a  framework  for  evaluating  alternative  evolutionary 
upgrade  paths  was  developed.  Methods  for  defining  a  target  system,  developing 
candidate  paths,  and  assigning  values  and  costs  to  those  paths  have  been  presented. 
These  values  and  costs  can  then  be  compared  given  a  set  of  decision  criteria  and  the 
"best"  system  with  its  associated  upgrade  path  can  be  selected.  It  would  then  be  up  to 
the  decision  makers  to  consider  any  further  issues  before  reaching  their  final  decision. 
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These  kinds  of  decisions  may  be  made  many  times  (for  each  upgrade 
procurement).  For  each  evaluation,  some  or  all  of  the  process  will  be  repeated;  if  the 
functions  to  be  supported  have  changed  (which  may  be  infrequent),  the  target  system 
functions  and  capabilities  could  be  modified,  giving  a  new  set  of  functions  with 
associated  values.  In  either  case,  technological  advances  will  make  new  capabilities 
available,  giving  new  sets  of  candidate  paths  with  their  associated  discounted  values  and 
costs. 

The  overall  goal  of  evaluating  alternatives  is  to  pick  the  "best"  alternative. 
For  this  framework,  the  "best"  alternative  is  the  system  that  provides  us  the  best  path 
(series  of  upgrades  over  time)  to  some  target  system  by  maximizing  the  value  of  the 
system  (and  system  path)  subject  to  cost,  resource,  and  risk  constraints.  The  value  and 
cost  of  a  candidate  path  that  spawns  from  a  base  system  will  be  measured  in  terms  of  the 
discounted  cost  and  the  discounted  value  of  each  upgrade  path.  This  framework  will  help 
the  decision  makers  by  providing  insightful  and  valuable  information  on  the  upgrade 
paths  of  the  decision  alternatives. 

4.  Application  of  the  Framework 

The  above  presentation  was  at  a  rather  general  and  abstract  level.  The 
following  chapter  will  provide  a  more  concrete  illustration  of  how  this  framework  can 
be  used  to  evaluate  a  real  C3  system,  the  USMC’s  current  TCO  system. 
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VI.  AN  ILLUSTRATED  EXAMPLE 


A.  INTRODUCTION 

1.  Purpose  of  this  Chapter 

The  purpose  of  this  chapter  is  to  provide  an  illustration  of  the  framework 
described  in  Chapter  HI.  The  illustration  will  focus  on  the  Marine  Coip’s  TCO  system 
described  in  Chapter  I.  The  illustration  should  clarify  how  the  methods  discussed  in  the 
previous  chapter  can  be  applied.  Values  and  costs  used  in  the  illustration  are  not  actual 
values  and  are  included  in  order  to  facilitate  the  illustration.  Furthermore,  only  a  small 
sample  of  the  functions  and  technological  capabilities  of  TCO  will  be  used  in  this 
illustration. 

2.  The  Problem 

The  problem  associated  with  the  Marine  Corp’s  Tactical  Combat  Operations 
System  is  a  common  one.  Most  new  military  C3  systems  will  require  a  Cost  and 
Operational  Effectiveness  Analysis  (COEA)  to  be  done  on  the  chosen  alternative  base 
systems.  In  the  case  of  TCO,  several  alternative  base  systems  were  selected23.  The 
TCO  COEA  team  is  currently  performing  an  analysis  on  the  alternatives  and  will 
recommend  to  the  decision  makers  the  alternative  that  best  meets  the  needs  of  the  Marine 
Corp’s  TCO  system  in  June  1993. 


23  See  Chapter  I  for  the  list  of  alternatives. 
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While  it  is  agreed  that  no  system  can  currently  satisfy  all  of  the  TCO 
requirements,  the  actual  goal  should  be  to  pick  the  system  that  offers  the  "best"  path 
toward  achieving  the  Target  TCO  system  requirements.  The  actual  requirements  for 
TCO  were  derived  from  the  approved  Mission  Need  Stateme  .1  MNS)  dated  16  June 
1992  and  are  divided  into  core  requirements  and  follow-on  requirements.  [Ref.  8] 

The  following  sections  present  the  illustration. 

B.  THE  ILLUSTRATION 

1.  Define  Target  System  Functions  and  Capabilities 

The  first  step  of  the  framework  begins  by  defining  the  target  TCO  system 
functions  and  capabilities.  The  functions  are  those  it  must  automate  and  the  technological 
capabilities  are  those  required  to  provide  automated  support  to  each  of  the  functions. 
Values  of  each  of  the  functions  to  the  force  are  then  estimated.  The  output  of  this  step 
is  a  table  highlighting  the  relationship  between  the  target  system’s  technological 
capabilities  and  the  functions  it  automates. 

The  Target  TCO  System  can  be  defined  by  using  the  core  and  follow-on 
requirements  found  in  the  MNS.  From  this  document  a  list  of  functions  requiring 
automation  is  derived.  To  obtain  functions  that  are  at  the  appropriate  level  of  complexity 
for  use  in  this  framework,  functional  decompositions  are  required.  The  functions  of  the 
target  system  should  be  at  a  level  that  would  allow  the  list  of  technological  capabilities 
required  to  automate  that  function  to  be  a  list  that  is  manageable  in  size.  To  illustrate 
this  point,  let  us  begin  with  the  relatively  high  level  function  of  producing  an  operations 
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order.  This  function  could  be  decomposed  into  many  lower  level  functions.  For  the 
purposes  of  this  illustration  only  a  subset  of  these  lower  level  functions  are  used.  Figure 
16  illustrates  the  simple  functional  decomposition  required  for  this  example.  The 
functions  chosen  for  this  illustration  are  the  mapping  function,  the  overlay  production 
function,  and  the  information  exchange  function  and  can  be  seen  in  Figure  16. 


Figure  16:  Example  of  the  Functional  Decomposition  Performed  for  Step  1 


Past,  present,  and  future  commanders  and  their  staffs  have  performed,  now 
perform,  and  probably  will  always  perform  these  functions.  The  level  of  automated 
support  will  change  as  technologies  mature.  The  requirement  given  in  the  MNS  for  TCO 
calls  for  these  functions  to  be  automated.  The  following  table  shows  the  relationship 
between  these  functions  and  their  associated  required  technological  capabilities.  For  the 
purpose  of  this  illustration,  the  technological  capabilities  listed  in  the  table  are  actually 
only  a  representative  subset  of  the  needed  capabilities  to  provide  automated  support  the 
these  functions.  The  table  in  Figure  17  will  serve  as  the  definition  of  our  TCO  Target 
System  functions  and  capabilities. 
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FUNCTION/CAPABILITY  TABLE  FOR  THE  TARGET  TCO  SYSTEM 


TECHNOLOGICAL 

CAPABILITIES 

FUNCTIONS 

Automate  Mapping 

Automate  Overlays 

Automate  Info  Exchange 

Selectable  level  of  Map  Detail 

X 

X 

Zoom-ln/Zoom-Out  Capability 

X 

X 

DMA  Product  Compatibility 

X 

X 

Scanned  Map  Capability 

X 

3-D  Map  Capability 

X 

Generate  Overlays 

X 

Disseminate  Overlays 

X 

X 

3-D  Overlay  Capability 

X 

Large  Color  Print  Capability 

X 

— 

Large  Screen  Display 

X 

LAN  Connectivity 

X 

Single  Channel  Radio  Connectivity 

X 

Switched  Backbone  Connectivity 

X 

X  -  Denotes  that  the  Technological  Capability  is  required  to  automate  that  Column  s  Function 


Figure  17:  Function/Capability  Table  for  the  TCO  Target  System 

Note  that  even  some  of  the  technological  capabilities  are  quite  complicated. 
Further  definitions  of  the  technological  capabilities  are  needed  in  order  to  determine 
exactly  when  a  particular  system  obtains  that  technological  capability  in  the  future.  For 
example,  the  technological  capability  of  DMA  product  compatibility  requires  that  the 
system  has  the  capability  to  build,  store,  retrieve,  display,  and  transmit  a  digital  map 
from  either  a  raster  or  vector  DMA  map  source.  [Ref.  8] 

The  next  part  of  this  step  involves  assigning  values  to  the  functions  in  the 
form  of  MOFEs  or  relative  weights.  As  discussed  in  Chapter  III,  a  method  needs  to 
devised  for  obtaining  a  value  for  each  function.  For  the  purpose  of  the  illustration  the 
elicitation  method  will  be  simulated  by  assigning  an  equal  weight  of  one  (1)  to  each 
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function.  This  serves  to  make  further  calculations  simpler  and  is  a  viable  option  for  the 
evaluators  if  time  and  resources  limit  the  construction  of  a  model  or  an  exercise  to  derive 
MOFEs  or  the  taking  of  a  survey.  Also,  if  the  evaluators  feel  that  relative  weights  won’t 
be  acceptable  to  the  decision  makers,  they  have  the  opportunity  to  assign  their  own 
weights  or  assign  equal  weights  to  each  function. 

Now  that  the  Target  System  functions  and  capabilities  are  defined  and  a  value 
of  one  (1)  given  to  each  of  the  functions,  it  is  time  to  proceed  to  the  next  step  of  the 
framework. 

2.  Define  Candidate  Paths 

The  second  step  of  the  framework  involves  identifying  all  of  the  alternative 
base  systems  in  terms  of  the  technological  capabilities  they  possess.  All  viable  paths  to 
the  target  system  functions  and  capabilities  that  spawn  from  each  alternative  are  then 
determined.  The  output  of  this  step  is  an  enumeration  of  all  candidate  paths. 

With  only  the  draft  final  COEA  report  available  at  the  time  of  this  writing, 
the  alternative  systems  listed  in  Chapter  I  may  not  be  all  that  the  USMC  will  consider. 
For  purposes  of  this  illustration,  candidate  paths  will  only  be  enumerated  for  two  of  the 
alternative  systems,  the  Naval  Tactical  Control  System-Afloat  (NTCS-A)  and  the 
Intelligence  Analysis  System  (IAS).  These  two  systems  will  become  the  alternative  base 
systems  for  TCO. 

Neither  alternative  obtains  all  of  the  technological  capabilities  required  to 
automate  the  three  target  system  functions,  but  each  currently  possesses  a  subset  of  them 
as  shown  in  Figures  18  and  19.  Figure  18  contains  a  function/capability  table  for  the 
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FUNCTION/CAPABILITY  TABLE  FOR  NTCS-A  BASE  SYSTEM 


TECHNOLOGICAL 

CAPABILITIES 


Selectable  level  of  Map  Detail 

Zoom-ln/Zoom-Out  Capability 

DMA  Product  Compatibility 

FUNCTIONS 

Automate  Mapping  Automate  Overlays  Automate  info  Exchange 


Scanned  Map  Capability 


3-D  Map  Capability 


Generate  Overlays 


Disseminate  Overlays 


3-D  Overlay  Capability 


Large  Color  Print  Capability 


Large  Screen  Display 


LAN  Connectivity 


Single  Channel  Radio  Connectivity 


Switched  Backbone  Connectivity 


X  -  Denotes  that  the  Technological  Capability  is  required  to  automate  that  Column  s  Function 
©  Denotes  that  the  System  possesses  this  Technological  Capability 


Figure  18:  Function/Capability  Table  for  the  NTCS-A 


NTCS-A  alternative  base  system  and  Figure  19  contains  the  function/capability  table  for 
the  IAS  alternative  base  system.  The  tables  show  what  technological  capabilities  the  two 
alternative  base  systems  have  today. 

The  next  step  involves  selecting  the  viable  paths  that  spawn  from  each 
alternative  that  will  eventually  fulfill  the  target  system’s  requirements.  In  the  case  of 
NTCS-A,  to  provide  the  required  automated  support  to  the  mapping  function,  scanned 
maps  and  three-dimensional  maps  technological  capabilities  are  required.  To  meet  the 
automation  of  overlays  requirement,  a  three-dimensional  overlay  capability  is  required 
and  to  automate  the  information  exchange  function,  LAN  connectivity  and  Switched 
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FUNCTION/ CAPABILITY  TABLE  FOR  IAS  BASE  SYSTEM 


TECHNOLOGICAL 

CAPABILITIES 

FUNCTIONS 

Automate  Mapping 

Automate  Overlays 

Automate  info  Exchange 

Selectable  level  of  Map  Detail 

(x) 

Zoom-ln/Zoom-Out  Capability 

mmomm 

© 

DMA  Product  Compatibility 

mmommm 

Scanned  Map  Capability 

X 

3-D  Map  Capability 

X 

1 

Generate  Overlays 

1 

Disseminate  Overlays 

vv 

~7Tj 

3-D  Overlay  Capability 

X 

Large  Color  Print  Capability 

00 

Large  Screen  Display 

X 

LAN  Connectivity 

X 

Single  Channel  Radio  Connectivity 

/s 

& 

Switched  Backbone  Connectivity 

x 

X  -  Denotes  that  the  Technological  Capability  is  required  to  automate  that  Column  s  Function 
®  Denotes  that  the  System  possesses  this  Technological  Capability 


Figure  19:  Function/Capability  Table  for  the  Intelligence  Analysis  System 

Backbone  connectivity  is  required.  Similarly,  in  the  case  of  IAS,  to  provide  the  required 
automated  support  to  the  mapping  function,  scanned  maps  and  three-dimensional  maps 
technological  capabilities  are  required.  To  meet  the  automation  of  overlays  requirement, 
a  three-dimensional  overlay  capability  and  large  screen  display  capability  is  required  and 
to  automate  the  information  exchange  function,  LAN  connectivity  and  Switched 
Backbone  connectivity  is  required. 

Through  cooperation  of  technical,  operational,  and  programmatic  experts, 
viable  timed  patterns  of  adding  these  capabilities  can  be  developed.  The  table  in  Figure 
20  summarizes  the  viable  paths  that  are  used  in  this  illustration.  Only  two  paths  for  each 
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THE  VIABLE  PATHS 


TECHNOLOGICAL 

CAPABILITIES 

1 

ALTERNATIVE  BASE  SYSTEMS  ; 

NTCS  -  A 

IAS 

PATH  1 

PATH  2 

PATH  3 

PATH  4 

Scanned  Map  Capability 

YEAR  1 

YEAR  2 

YEAR  1 

YEAR  2  i 

3-D  Map  Capability 

YEAR  2 

. 

YEAR  4 

YEAR  2 

YEAR  3 

3-D  Overlay  Capability 

YEAR  3 

YEAR  4 

YEAR  3 

YEAR  4 

Large  Screen  Display 

N/A 

N/A 

YEAR  4 

YEAR  3 

LAN  Connectivity 

YEAR  4 

YEAR  1 

YEAR  4 

YEAR  1 

Switched  Backbone  Connectivity 

YEARS 

YEAR  5 

YEAR  5  YEAR  1 

NOTE:  Contents  of  table  denotes  what  year  a  particular  path  will  obtain  that  Technological  Capability 


Figure  20:  The  Viable  Paths 

alternative  base  system  has  been  chosen  for  simplicity,  although  there  may  actually  be 
many  viable  paths.  The  four  paths  will  become  the  Candidate  Paths  for  the  evaluation. 
The  table  in  Figure  20  indicates  for  each  alternative  base  system’s  path,  what  year  a 
particular  technological  capability  will  be  added  to  the  base  system.  As  discussed  in 
Chapter  III,  selection  of  these  candidate  paths  require  experts  in  many  disciplines  to 
agree  on  what  can  be  considered  viable  upgrade  paths.  One  method  would  be  to  charter 
an  independent  agency  to  perform  this  task.  With  the  candidate  paths  determined,  the 
evaluator  can  move  on  to  the  next  step  of  getting  the  discounted  values  and  costs  of  each 
candidate  path. 

3.  Get  Values  and  Costs 

The  third  step  of  the  framework  involves  assigning  functionally  derived 
values  and  capability  derived  costs  to  each  candidate  path  at  discrete  time  intervals. 
These  values  and  costs  are  then  discounted  to  present  values  and  costs  and  added 
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together.  The  output  of  this  step  is  a  single  discounted  value  and  a  single  discounted  cost 
associated  with  each  candidate  path. 

Figure  21  graphically  illustrates  what  each  candidate  path  looks  like.  For 
simplicity,  only  a  time  span  of  five  years  is  chosen.  It  is  clear  that  each  candidate  path 
is  simply  a  timed  insertion  of  technological  capabilities. 


YEAR 


'HE  CANDIDATE  !  H5 


Figure  21:  The  Viable  Candidate  Paths 


PLANNING 

HORIZON 


As  technological  capabilities  are  added,  the  system  will  periodically  obtain  enough 
technological  capabilities  to  provide  the  required  level  of  automated  support  to  one  or 
more  of  the  target  system  functions.  Each  candidate  path  will  eventually  succeed  in 
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reaching  the  required  level  of  automation  stated  in  the  definition  of  the  target  system 
functions  and  capabilities. 

The  overall  discounted  value  of  a  candidate  path  is  the  sum  of  the  discounted 
values  of  each  function.  The  discounted  value  of  a  function  depends  on  when  (e.g. ,  what 
year)  that  function  is  successfully  automated  in  a  candidate  path.  A  simple  method  for 
discounting  the  value  of  a  function  is  illustrated  in  Figure  22.  The  graph  shows  the 
relationship  between  the  value  of  a  function  and  the  year  in  which  it  is  added  to  the 
candidate  path.  If  the  system  obtains  a  function  today,  it  receives  the  full  value  of  that 
function  (one).  Likewise,  if  the  function  is  not  automated  until  say  10  years  from  now, 
it  only  receives  half24  the  determined  value  of  the  function  (one-half).  How  the  graph 
behaves  in  between  the  present  and  the  planning  horizon  depends  on  the  time  utility  or 
temporal  importance  the  users  place  on  receiving  a  particular  function25.  Functions  that 
are  added  sooner  will  contribute  more  value  to  the  overall  value  of  a  candidate  path  than 
if  they  were  added  later. 

To  compute  the  discounted  value  of  the  functions,  the  linear  relationship  in 
Figure  22  is  used  for  simplicity.  This  yields  the  following  equation  for  determining  the 
discounted  value  of  a  function: 


24  The  residual  value  of  one-half  was  arbitrarily  chosen  by  the  authors.  Evaluators  should 
feel  free  to  pick  an  appropriate  residual  or  terminal  value  of  obtaining  a  particular  function. 

25  A  thorough  discussion  on  Utility  theory  can  be  found  on  page  258  of  Reference  29. 
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OTi"1*e(^)  (S> 

Where  DVj  is  the  discounted  value  of  the  i*  function,  1  is  the  value  of  each 
function  at  t  =  0,  and  t  is  the  year  or  time  period  that  the  candidate  path  successfully 
automates  the  function  i. 


DISCOUNTING  OF  FUNCTIONS 


YEAR  IN  WHICH  SYSTEM  GAINS  FUNCTION 


Figure  22:  How  the  Value  of  Functions  are  Discounted  to  the  Present 
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To  find  the  overall  discounted  value  of  the  candidate  path,  the  individual 
discounted  values  of  each  function  are  simply  added.  The  following  equation  will  be 
used: 

N 

ODV=Yj  DVi  (6) 

i= 1 

Where  ODV  is  the  overall  discounted  value  of  the  candidate  path,  i  is  a 
counter  for  the  individual  functions,  N  is  the  total  number  of  functions,  and  DV,  is  the 
discounted  value  of  the  i*  function. 

Costs  of  the  candidate  paths  that  the  framework  uses  are  the  cost  of  the 
alternate  base  system  if  bought  today  and  the  cost  of  adding  a  particular  technological 
capability  to  given  base  system.  Costs  of  adding  a  particular  technological  capability 
may  be  different  for  each  alternative  base  system  because  each  system  may  require 
different  combinations  of  hardware  and/or  software  to  provide  the  required  level  of 
automation  depending  on  the  current  configuration  of  a  given  base  system.  Figure  23 
shows  the  estimated  costs  of  adding  the  needed  technological  capabilities  to  the  two 
alternative  base  systems  chosen. 

Discounted  costs  of  adding  technological  capabilities  are  computed  using  the 
standard  discounting  function: 
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COST  OF  PROVIDING  ADDITIONAL  TECHNOLOGICAL  CAPABILITIES 


TECHNOLOGICAL 

CAPABILITIES 

ALTERNATIVE  BASE  SYSTEMS 

NTCS- A 

IAS 

Scanned  Map  Capability 

S  400,000 

5  400,000 

3-D  Map  Capability 

S  207,000 

$  207,000 

3  D  Overlay  Capability 

S  207,000 

$  207,000 

Large  Screen  Display 

N,'A 

$  355,000 

LAN  Connectivity 

S  100,000 

S  60,000 

Switched  Backbone  Connectivity 

S  473,000 

$  120,000 

NOTE:  Contents  of  table  denotes  cost  of  adding  the  Technological  Capability  to  a  particular  Base  System 
Costs  were  estimated. using  data  from  the  CCEA  Final  Report  (Oaft),  Appendix  <  (Costs) 


Figure  23:  Technological  Capabilities  and  their  Costs 


DCr 


L(i^)yJ 


C7 


(7) 


Where  DCj  is  the  discounted  cost  of  adding  the  j*  technological  capability, 
r  is  the  discounting  factor  or  interest  rate,  y  is  the  year  or  time  period,  and  C}  is  the  cost 
of  adding  the  j*  technological  capability  to  the  system. 

To  calculate  the  overall  discounted  cost  of  the  candidate  path,  the  initial  cost 
of  the  alternative  base  system  is  added  to  the  discounted  cost  of  each  technological 
capability  that  is  added  to  the  candidate  path.  The  following  equation  is  used  to  compute 
the  overall  discounted  cost  of  a  candidate  path: 


M 

ODC-  IC  +Y,  DCj  W 

j-o 

Where  ODC  is  the  overall  discounted  cost  of  a  candidate  path,  ICj  is  the 
initial  cost  of  buying  the  alternative  base  system,  M  is  the  total  number  of  technological 
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capabilities  that  are  added  to  a  candidate  path,  and  DCj  is  the  discounted  cost  of  adding 
the  j111  technological  capability. 

Figure  24  illustrates  how  the  above  calculations  are  used  to  calculate  the 
overall  discounted  value  and  cost  of  the  first  candidate  path. 
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FUNCTIONS  AUTOMATED 
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tons 

M2pp.ng 

Gver&ys 
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> 

0 

n 

w 

1 

1  |  G 

i 

DISCOUNTED 

VALUE 

G 

G 

0.9 

0.65  !  0 

1 

Q  75 

COST 

15D0C 

mammam 

237< 

mm 

*»73K 

DISCOUNTED 

COST 

1500K 

353  6K  j  1 7 IK 

1 

155  5K 

60.3K 

293  7K 

OVERALL  DISCOUNTED  VALUE  Or  THE  CANDIDATE  PATH  =  0  9  *  0  65  ♦  0.75  =  23 

OVERALL  DISCOUNTED  COST  OF  THE  CANDIDATE  PATH  =  1500  053  6  ♦  171  -  155.5  *  68.3  ♦  233  7 


Figure  24:  Computation  of  the  Discounted  Value  and  Cost  of  a  Candidate  Path 


The  procedure  for  finding  the  overall  discounted  value  and  cost  of  a  candidate 
path  is  simple.  The  first  step  involves  determining  when  (or  at  which  time  periods)  the 
candidate  path  will  succeed  in  automating  the  functions  of  the  target  system.  As  can  be 
seen  in  Figure  24,  the  first  candidate  path  succeeds  in  providing  the  required  automated 
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support  to  the  mapping  function  in  year  two.  The  overlay  function  is  obtained  in  year 
three  and  the  information  exchange  function  is  obtained  in  year  five.  The  second  step 
requires  the  use  of  Equation  (1)  to  compute  the  discounted  value  of  each  of  the  functions. 
The  third  step  uses  Equation  (3)  to  calculate  the  discounted  costs  of  the  technological 
capabilities  that  are  added  to  the  system.  The  fourth  and  fifth  steps  use  Equations  (2) 
and  (4)  to  compute  the  overall  discounted  value  and  cost  of  the  candidate  path.  As  can 
be  seen  from  Figure  24,  calculations  for  the  first  candidate  path  yield  a  discounted  value 
of  2.5  and  discounted  cost  of  2552.  IK.  Figure  25  shows  the  results  of  doing  these 
calculations  on  the  remaining  candidate  paths. 

The  next  step  of  the  framework  discusses  the  selection  of  a  candidate  path 
using  the  values  and  costs  that  were  calculated  in  this  step. 


DISCOUNTED  VALUES  AND  COSTS  0?  THE  CANDIDATE  PATHS 


. . . . 

ALTERNATIVE  BASE  SYSTEMS 

NTC5-A 

IAS 

PATH  1 

PATH  2 

PATH  3 

PATH  4 

DISCOUNTED  VALUE 

25 

2.35 

2.5 

2.55 

DISCOUNTED  COST 

2552 TK 

_ 

24S3K 

2548K 

2111.5K 

Figure  25:  The  Discounted  Value  and  Cost  of  Each  Candidate  Path 
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4.  Select 


The  last  step  of  the  framework  involves  selecting  the  best  candidate  path.  In 
this  kind  of  decision,  the  "best"  candidate  path  is  the  one  that  maximizes  value  subject 
to  cost,  resource,  and  risk  constraints26.  The  rule  or  problem  is  stated  as: 

Maximize:  Value 

Subject  to:  •  Cost 

•  Resource 

•  Risk 

An  easy  procedure  for  selecting  the  best  candidate  path  given  the  data  like 
that  in  Figure  25,  is  to  first  remove  the  candidate  paths  that  don’t  satisfy  at  least  one  of 
the  constraints  from  consideration.  For  the  purpose  of  the  illustration,  say  a  budget  of 
2500K  has  been  allocated  for  the  C3  system  and  that  all  candidates  meet  the  resource  and 
risk  constraint.  From  Figure  25,  candidate  paths  one  and  three  exceed  the  established 
cost  constraint,  so  they  will  not  be  considered.  The  next  step  is  to  select  from  the 
remaining  candidate  paths,  the  one  that  has  the  greatest  value.  For  the  illustration, 
candidate  path  four  is  selected-’ 


While  this  framework  docs  not  expand  on  the  resource  and  risk  constraint,  they  are  still 
mportant  issues  that  deserve  a  tair  amount  ot  attention  tor  an  actual  evaluation 

(  undulate  path  tour  had  the  greatest  value  because  it  succeeded  in  automating  some  ot 
he  turn  turns  stumer  than  the  other  paths  It  also  hail  the  least  urst  because  the  more  ex|»erisi\e 
ci  hnologK.il  capabilities  were  added  later  in  its  path  which  allowed  them  to  lake  advantage  ot 
he  discounting 
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C.  CONCLUSIONS 


The  illustration  is  intended  only  to  give  the  reader  a  general  idea  of  how  to  apply 
the  concepts  and  procedures  of  this  framework.  For  that  purpose,  the  illustration  is  an 
extremely  simplified  one.  Evaluations  of  actual  systems  would  begin  with  a  much  bigger 
function/capability  table  for  the  definition  of  the  target  system  functions  and  capabilities 
and  would  require  more  data.  Nonetheless,  the  steps  of  the  framework  are  fairly  simple 
to  follow  and  flow  logically  from  one  step  to  the  next.  The  tables  and  data  produced  by 
this  framework  provide  the  decision  makers  with  invaluable  insight  into  how  the  various 
alternatives  will  change  over  time  and  may  highlight  evolutionary  issues  that  have  been 
overlooked  in  the  past.  This  framework  will  result  in  decisions  that  have  taken  into 
account  the  difficult,  but  ever  present,  temporal  component  of  evolving  Cy  systems. 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

1.  The  C3  Systems  Procurement  Environment 

Chapter  II  presented  a  discussion  of  the  technology  initiatives  that  will  impact 
C3  systems.  The  Evolutionary  Acquisition  concept  was  introduced  and  topics  such  as 
Non-Developmental-Items,  Commercial-Off-the-Shelf  products,  and  open  architecture 
standards  were  presented.  It  is  important  that  the  procurement  environment  in  which  C3 
systems  are  procured  be  understood  by  the  evaluators.  Important  factors  of  the 
procurement  environment  that  effect  C3  systems  include;  the  recent  increased  rate  of 
technological  change,  the  mandated  use  of  the  Evolutionary  Acquisition  concept,  the  use 
of  NDI  and  COTS  products,  and  the  evolving  open  architecture  standards 

2.  Current  Frameworks 

Chapter  II  also  presented  a  cross-section  of  some  of  the  current  C'  system 
evaluation  frameworks  The  Mission-Oriented  Approach,  the  Modular  Command  and 
Control  Evaluation  Structure,  and  the  COLA  team's  evaluation  approach  were  discussed 
and  their  applicability  to  current  (‘  systems  evaluation  highlighted  None  of  these 
frameworks  or  methodologies  spccituallv  deal  with  the  temporal  component  ot  (" 
sv  stems 
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3.  The  New  Framework 

Chapter  HI  presented  a  new  framework  that  focuses  the  evaluation  of 
alternatives  on  their  evolutionary  upgrade  paths.  The  framework  presents  a  method  that 
could  be  useful  to  decision  makers  in  choosing  between  alternative  C3  systems.  The 
framework  contains  four  steps: 

1.  Define  target  system  functions  and  capabilities. 

2.  Define  all  viable  upgrade  paths  from  each  alternative  base  system  to  the  target 
system;  each  path  becomes  a  candidate  path. 

3.  Develop  discounted  value  and  discounted  cost  for  each  candidate  path. 

4.  Select  the  candidate  path  that  maximizes  value  subject  to  stated  cost,  resource, 
and  risk  constraints. 

Methods  and  procedures  for  accomplishing  each  step  was  presented. 

4.  The  Illustration 

Chapter  IV  provided  an  illustration  of  the  framework.  The  illustration 
focused  on  the  Marine  Corp’s  TCO  system  described  in  Chapter  I.  The  illustration 
clarified  how  the  methods  of  the  framework  can  be  applied. 

B.  CONCLUSIONS 

1.  The  C1  Systems  Procurement  Environment 

The  following  conclusions  can  be  made  in  regard  to  the  environment  m  which 
("  systems  are  procured 


1.  That  C3  systems  must  capitalize  on  emerging  technologies  to  remain  mission 
capable. 

2.  That  C3  systems  will  incorporate  evolutionary  upgrades  throughout  their  useful 
life  cycle  if  procured  through  evolutionary  acquisition. 

3.  That  most  of  these  evolutionary  upgrades  will  be  composed  of  NDI  or  COTS 
products  that  adhere  to  "open  system"  standards. 

4.  That  current  evaluation  frameworks  do  not  base  their  evaluations  on  the 
temporal  component  of  C3  systems. 


2.  The  Framework  as  an  Effective  Tool  for  Evaluation 

The  new  framework  presented  here  offers  an  alternative  approach  to  C3 
systems  evaluations.  The  framework’s  methods  for  dealing  with  upgrade  paths  can  be 
widely  applied  to  many  systems.  C3  systems  of  today  and  in  the  future  will  constantly 
change  to  keep  up  with  state-of-the-art  technologies.  This  aspect,  called  the  temporal 
component,  is  directly  addressed  by  this  framework. 

This  framework  can  be  a  very  useful  tool  for  evaluating  C3  systems  or 
subsystems  that  will  undergo  many  evolutionary  upgrade  changes  throughout  their  useful 
life  cycle.  The  author  concludes  that  evaluations  of  alternatives  can  be  based  on 
cost/benefit  analysis  performed  on  the  perceived  future  upgrade  paths  of  the  alternatives. 

3.  The  TCO  Problem 

The  TCO  program  will  no  doubt  go  through  main  changes  during  its  iite 
cycle.  The  concept  is  a  valid  one  and  it  n  g reads  needed  to  support  the  aurtichter  ■> 


todav  s  ens  ironmenl 


It  is  almost  certain  that  some  new  baseline  system  will  be  bought  to  fulfill  the 
TCO  requirements.  The  next  upgrade  to  TCO  will  become  a  new  baseline  system.  This 
baseline  system  will  form  the  core  on  which  evolutionary  upgrades  will  be  incrementally 
added  during  its  useful  life  cycle.  Several  different  acquisition  strategies  are  currently 
being  considered  by  the  project  office,  but  one  thing  is  certain  about  the  program,  many 
periodic  upgrades  will  be  integrated  into  the  system.  At  each  decision  point,  choices  will 
have  to  be  made  as  to  which  upgraded  product  to  buy.  This  framework  could  be  used 
at  these  subsequent  decision  points  to  help  the  USMC  pick  the  "best"  product. 

C.  RECOMMENDATIONS 

This  framework  represents  an  initial  effort  at  basing  the  evaluation  of  alternatives 
on  their  future  evolutionary  upgrade  paths.  General  concepts  and  procedures  were 
introduced.  Areas  that  could  benefit  greatly  by  further  research  include: 

1.  More  streamlined  methods  for  determining  target  system  functions  and 
capabilities. 

2.  Methods  that  more  accurately  predict  future  upgrade  technological  capabilities 
and  costs. 

3.  Procedures  that  would  expand  the  framework  to  include  evaluations  of  the 
uncertainty  and  risk  issues. 
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APPENDIX  A:  GLOSSARY 


ACE 

Aviation  Combat  Element 

ACMC 

Assistant  Commandant  of  the  Marine  Corps 

ADM 

Acquisition  Decision  Memorandum 

ADPE-FMF 

Automatic  Data  Processing  Equipment-Fleet  Marine  Force 

AE 

Acquisition  Executive 

AFATDS 

Advanced  Field  Artillery  Tactical  Data  System 

A  HP 

Analytical  Hierarchy  Process 

AIC 

Automated  Information  Center 

AOA 

Amphibious  Operational  Area 

APO 

Acquisition  Project  Officer 

ARC 

Atlantic  Research  Corporation 

ASD 

Assistant  Secretary  of  Defense 

ASP 

Acquisition  Strategy  Plan 

ASPO 

Acquisition  Sponsor  Project  Officer 

ATACCS 

Army  Tactical  Automated  Command  and  Control  System 

ATCCS 

Army  Tactical  Command  and  Control  System 

ATDL-1 

Army  Tactical  Data  Link-1 

ATO 

Air  Tasking  Order 

AUTODIN 

Automatic  Digital  Network 

C2 

Command  and  Control 

C2MP 

Command  and  Control  Master  Plan 

C3 

Command,  Control,  and  Communications 

C3I 

Command,  Control,  Communications,  and  Intelligence 

CT 

Command,  Control,  Communications,  Computers,  and  Intelligence 
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C4I2 

CATF 

CE 

CECOM 

CEO 

CG 

CIM 

crp 

CMC 

coc 

COEA 

COTS 

CP 

CSI 

CSSE 

CTIS 

DCA 

DISA 

DMA 

DoD 

DOS 

DPM 

EA 

EPLRS 

FIPS 

FMF 

GCE 

GOR 


Command,  Control,  Communications,  Computers, 
Intelligence,  and  Interoperability 
Commander  Amphibious  Task  Force 
Command  Element 

U.S.  Army  Communications-Electronics  Command 

Chief  Executive  Officer 

Commanding  General 

Corporate  Information  Management 

Combat  Information  Processor 

Commandant  of  the  Marine  Corps 

Combat  Operations  Center 

Cost  and  Operational  Effectiveness  Analysis 

Commercial-Off-The-Shelf 

Command  Post 

Command  Systems  Incorporated 
Combat  Service  Support  Element 
Command  Tactical  Information  System 
Defense  Communications  Agency 
Defense  Information  Systems  Agency 
Defense  Mapping  Agency 
Department  of  Defense 
Disk  Operating  System 
Deputy  Program  Manager 
Evolutionary  Acquisition 

Enhanced  Position  Location  and  Reporting  System 
Federal  Information  Processing  Standard 
Fleet  Marine  Force 
Ground  Combat  Element 
General  Operational  Requirement 
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GOSIP 

GUI 

HQMC 

IAS 

IEC 

ISO 

JTIDS 

LAN 

MAGTF 

MARCORSYSCOM 

MCASS 

MCCDC 

MCES 

MCHS 

M COTEA 

MCS 

MCTSSA 

MOA 

MOE 

MOFE 

MOP 

MORS 

MEF 

MEU 

MIFASS 

MNS 

MTACCS 

NDI 

NMSD 


Government  Open  System  Interconnection  Profile 

Graphical  User  Interface 

Headquarters  Marine  Corps 

Intelligence  Analysis  System 

International  Electrotechnical  Committee 

International  Standards  Organization 

Joint  Tactical  Information  Dissemination  System 

Local  Area  Network 

Marine  Air  Ground  Task  Force 

Marine  Corps  Systems  Command 

MTACCS  Common  Application  Support  Software 

Marine  Corps  Combat  Development  Command 

Modular  Command  and  Control  Evaluation  Structure 

MTACCS  Common  Hardware  Support 

Marine  Corps  Operational  Test  and  Evaluation  Activity 

Maneuver  Control  System 

Marine  Corps  Tactical  Systems  Support  Activity 

Mission  Oriented  Approach 

Measure  of  Effectiveness 

Measure  of  Force  Effectiveness 

Measure  of  Performance 

Military  Operations  Research  Society 

Marine  Expeditionary  Force 

Marine  Expeditionary  Unit 

Marine  Integrated  Fire  and  Air  Support  System 

Mission  Need  Statement 

Marine  Corps  Tactical  Automated  Command  and  Control  System 

Non-Developmental-Item 

National  Military  Strategy  Document 
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NTCS-A 

o&s 

OMB 

PM 

POSIX 

R&D 

RDT&E 

SMART 

SOCEX 

TCEM 

TCO 

TNS 

US 

USMTF 

USPACOM 

WAN 


Naval  Tactical  Command  System  -  Afloat 
Operations  and  Support 
Office  of  Management  and  Budget 
Program  Manager 

Portable  Operating  System  Interface  -  UNIX 
Research  and  Development 
Research  Development  Testing  &  Evaluation 
Simple  Multi-Attribute  Rating  Technique 
Special  Operations  Command  Exercise 
Tactical  Communications  Interface  Module 
Tactical  Combat  Operations  system 
Tactical  Network  Server 
United  States 

United  States  Message  Text  Formats 
U.S.  Pacific  Command 
Wide  Area  Network 
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